Dokumentacja REST API v 3.0. Kraków, 7 marca FreshMail, ul. Fabryczna 20a, Kraków tel , freshmail.

Podobne dokumenty
Dokumentacja REST API v 3.0

Dokumentacja REST API v 3.0

Dokumentacja REST API v 3.0

Dokumentacja REST API v 3.0

Dokumentacja REST API v 3.0

DOKUMENTACJA TECHNICZNA SMS API MT

Dokumentacja REST API v 3.0

Dokumentacja REST API v 3.0

Dokumentacja REST API v 3.0

Specyfikacja API 1.0. Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST

Specyfikacja HTTP API. Wersja 1.6

API transakcyjne BitMarket.pl

Dokumentacja smsapi wersja 1.4

Wszystkie dane powinny być przekazane za pomocą metody POST, zakodowane za pomocą funkcji urlencode().

Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl

API System Partnerski

Dokumentacja Techniczna 1.2. Webtoken MT. Uruchomienie subskrybcji MT poprzez serwis WWW

API przekazy masowe - Dokumentacja. v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/ Poznań.

Dokumentacja SMS przez FTP

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Dokumentacja 2SMS

Automater.pl zdalne tworzenie i zarządzanie transakcjami dokumentacja API wersja 0.1

Dokumentacja interfejsu Webservices API. Wersja 2.0 [12 stycznia 2014]

Specyfikacja Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań.

Specyfikacja techniczna. mprofi Interfejs API

Dokumentacja Techniczna SMS MO

Dokumentacja Techniczna. Dokumentacja techniczna usługi płatności mobilnych

QualitySpy moduł reports

Gatesms.eu Mobilne Rozwiązania dla biznesu

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (

INFAKT API - opis (ver. 0.8)

Dokumentacja techniczna SMS MO

Specyfikacja Techniczna 2.0. Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Remote Quotation Protocol - opis

Terytorialna analiza danych

Gatesms.eu Mobilne Rozwiązania dla biznesu

Orange Send MMS. Autoryzacja. Metoda HTTP. Parametry wywołania. API wyślij MMS dostarcza wiadomości MMS. Basic POST

Spis treści 1. Założenia ogólne 2. Wymagania 3. Typy SMSów 4. Statusy SMSów 5. Wysyłanie SMSów - Web API 6. Wysyłanie SMSów - 7.

Ogólnopolskie Repozytorium Prac Dyplomowych

Funkcje dodatkowe. Wersja 1.2.1

Dokumentacja techniczna API systemu SimPay.pl

Przewodnik użytkownika (instrukcja) AutoMagicTest

DOKUMENTACJA INTERFEJSU API - HTTPS

API transakcji - Dokumentacja. v 2. 2, marzec 2017 KIP S.A. ul. Św. Marcin 73/ Poznań.

PayPo API v.2.0. Dokument zawiera specyfkaccę techniczną REST API PayPo.pl w wersci 2.0. Wersja dokumentu. Wykaz zmian

SSL (Secure Socket Layer)

BRAMKA HTTP SMS XML Dokumentacja techniczna. wersja 3.32

Dokumentacja SQL API 1

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center

Dokumentacja interfejsu HTTPD. Platforma BSMS.PL Instrukcja podłączenia po przez http

INSTRUKCJA OBSŁUGI Wersja: 1.8

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Płatności CashBill - Kody

DOKUMENTACJA TECHNICZNA KurJerzyAPI wersja 1.0

Dokumentacja serwera REST do obsługi rezerwacji w systemie SaNAtoRIUm.pro

Technologie internetowe

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

OPIS TECHNICZNY SYSTEM HOSTED SMS

INSTRUKCJA OBSŁUGI Wersja: 2.5

System DiLO. Opis interfejsu dostępowego v. 2.0

DirectBilling dokumentacja techniczna

Programowanie Komponentowe WebAPI

Exchange Konfiguracja protokołu SSL/TLS w serwerze pocztowym Exchange wersja 1.0

Funkcje dodatkowe. Wersja 1.2.1

Przewodnik użytkownika (instrukcja) AutoMagicTest

Instrukcja korzystania z usługi 2SMS. Wersja 2.0 [12 stycznia 2014] bramka@gsmservice.pl

SMS Kod Automatyczny

Obiekty sportowe (mapy rastrowe)

Formularze. Instrukcja MailSolutions Zarządzanie Panelem Administratora Aplikacja zgodna wymogami RODO

Implementacja mechanizmu SkyCashClick Wersja 0.1

Dokumentacja techniczna SMS MO

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Dokumentacja API BizIn

Spis treści INTERFEJS (WEBSERVICES) - DOKUMENTACJA TECHNICZNA 1

Sieci komputerowe i bazy danych

Zarządzanie licencjami dla opcji Fiery na komputerze klienta

Spis treści DOKUMENTACJA TECHNICZNA. STS API wersja 1.1

WebNotarius. Specyfikacja techniczna komunikacji z usługą WebNotarius. wersja 1.1

Kurier DHL XL by CTI. Instrukcja

Panel administracyjny serwera: admin.itl.pl

Instrukcja do programu Przypominacz 1.6

Instrukcja do programu Przypominacz 1.5

KURIER XL BY CTI DLA SIÓDEMKA

Ministerstwo Finansów

DOKUMENTACJA INTERFEJSU MY MYSQL. Platforma SMeSKom instrukcja podłączenia poprzez mysql Protokół w wersji 3.1

Architektura aplikacji

Ministerstwo Finansów

Dokumentacja API statystyk

Exchange Konfiguracja protokołu SSL/TLS w serwerze pocztowym Exchange wersja 1.0 UNIZETO TECHNOLOGIES S.A.

Podręcznik Integracji

Rejestracja nowych Dystrybutorów

Spis treści. Rejestracja/logowanie. Zmiana numeru konta klienta. Tworzenie nowej przesyłki. Zamawianie kuriera

Aktualizacja SMSFall v Data publikacji:

Wprowadzenie... 2 Komunikaty ogólne... 3 Wysyłanie wiadomości SMS o jednakowej treści... 7 Wysyłanie spersonalizowanych wiadomości SMS...

Exchange Konfiguracja protokołu SSL/TLS w serwerze pocztowym Exchange wersja 1.0

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

System automatyki domowej. Nexo.API Protokół Karty komend NXW396

Dokumentacja. Wersja: 1.5 Ostatnio zmodyfikowano: Strona 1

Transkrypt:

Dokumentacja REST API v 3.0 Kraków, 7 marca 2012 FreshMail, ul. Fabryczna 20a, 31-553 Kraków tel. +48 12 617 61 40, info@freshmail.pl, freshmail.pl

Wersja dokumentu: 1.0 Autorzy: Tadeusz Kania <tadeusz.kania@freshmail.pl>, Piotr Suszalski <piotr.suszalski@freshmail.pl> Opis API API systemu FreshMail zostało zrealizowane według wzorca REST. Komunikacja polega na wysłaniu żądania HTTP pod adres https://app.freshmail.pl/rest/ i ewentualnym przesłaniu wymaganych danych. Odpowiedź jest zwracana w formacie JSON. Uwierzytelnienie Każde wysłane żądanie po API wymaga uwierzytelnienia. Uwierzytelnienie następuje poprzez wysłanie nagłówków HTTP o nazwach: X-Rest-ApiKey zawiera unikalny klucz dostępu do API, każdy z klientów posiada swój unikalny klucz API. subskrypcje lista subskrypcyjna opcje zaawansowane i API X-Rest-ApiSign zawiera podpis żądania. Podpis jest generowany na podstawie parametrów wysyłanych w żądaniu oraz na podstawie ApiSecret. Schemat generowania X-Rest-ApiSign znajduje się poniżej: sha1( ApiKey + GET_data + POST_data + ApiSecret ) gdzie: ApiKey GET_data POST_data ApiSecret 32 znakowy Api key. pełna ścieżka dostępu np. /rest/ping, /rest/mail itp. Więcej szczegółów w sekcji Ścieżka dostępu. dane POST umieszczone w żądaniu. Jeśli w żądaniu znajdują się tylko dane GET to wartość POST_data jest pusta. 40 znaków, unikalny sekret dla każdego z klientów. W przypadku skompromitowania klucza należy bezzwłocznie wygenerować nowy.

Odpowiedzi API Odpowiedź na każde żądanie wysłane do API jest w formacie JSON, np. {"status":"ok","data":[1,2,3]} Jeśli zapytanie powiedzie się wtedy pod kluczem status będziemy mieli wartość 'OK'. Jeśli metoda ma zwrócić dane będą one pod kluczem data. Natomiast jeśli wystąpi błąd pod kluczem status będzie wartość ERROR, a pod kluczem errors znajdzie się opis błędów jakie wystąpiły wraz z kodami błędów. W przypadku błędu kod HTTP zwracany w nagłówku jest adekwatny do zaistniałego błędu, czyli np. 404, 403 itp. W przypadku braku błędu kod HTTP to 200. Obsługa błędów W razie wystąpienia błędu status odpowiedzi jest równy ERROR natomiast pole errors zawiera opis słowny błędu oraz kod błędu, np. {"errors":[ {"message":"brak tematu emaila", "code": 1202} ], "status":"error"} lub {"errors":[ {"message": "Błędny adres odbiorcy", "code": 1201}, {"message": "Brak tematu emaila", "code": 1202} ], "status":"error"}

Ścieżka dostępu Każda z akcji jaką można wykonać ma swoją osobną ścieżkę dostępu. Ścieżka zbudowana jest w następujący sposób: /rest/[controller]/[action]/[param]/[param]/[param] Controller Action param nazwa kontrolera np. ping, mail, itp. nazwa akcji w obrębie kontrolera. parametr, nie może zawierać znaku /, w większości przypadków dodatkowe parametry GET są zbędne. Jeśli są wymagane to ilość oraz ich format jest podany w opisie akcji. Ogólne kody błędów 500 Błąd serwera (Internal Server Error). 1000 Brak autoryzacji. 1001 Nie znaleziono kontrolera / akcji. 1002 Nieobsługiwany protokół. Proszę skorzystać z protokołu https. 1003 Nieobsługiwany rodzaj żądania, np. wysłano GET, a oczekiwano POST.

Opis metod używanych w API Ping testowanie Kontroler ten służy do przetestowania poprawności działania API. Osobno można przetestować poprawność działania żądań typu GET oraz żądań typu POST. Wywołanie: GET /rest/ping W odpowiedzi serwer zwróci pong. Wywołanie: POST /rest/ping W odpowiedzi serwer zwróci dane które wysyła się w POST.

Maile transakcyjne wysyłanie pojedynczych maili Kontroler służy do wysyłki pojedynczych maili transakcyjnych. Domyślnie wszystkie parametry powinny być przekazane w kodowaniu UTF-8. Można to zmienić korzystając z parametru encoding. Wywołanie: POST /rest/mail Dane w POST: subscriber Wymagane Adres email subskrybenta do którego wysyłamy email. subject Wymagane Tytuł emaila. html Wymagane* Treść html emaila (wymagana jeśli nie ma treści text). text Wymagane* Treść tekstowa emaila (wymagana jeśli nie ma treści html). from Opcjonalne Pole Od, jeśli będzie puste w to miejsce wstawi się domyślny adres nadawcy z systemu. from_name Opcjonalne Pole Nazwa nadawcy, jeśli będzie puste w to miejsce wstawi się domyślna nazwa nadawcy z systemu. reply_to Opcjonalne Pole Odpowiedz do, jeśli będzie puste w to miejsce wstawi się domyślny adres nadawcy z systemu. encoding Opcjonalne Kodowanie w jakim ma zostać wysłany email. Domyślnie jest to UTF- 8. Pamiętaj, że email musi być przekazany w tym samym kodowaniu, które jest przekazane w parametrze encoding. Obsługiwane kodowania to: UTF-8, iso-8859-2 Kody błędów: 1201 Błędny adres subskrybenta. 1202 Brak tematu maila. 1203 Brak treści HTML oraz tekstowej. 1204 Błędny adres odpowiedz do. 1205 Błędny adres email nadawcy. 1206 Nazwa nadawcy nie może być pusta. 1207 Przekroczono dzienny limit wysłanych maili. 1208 Nieobsługiwane kodowanie. 1250 Nie udało się wysłać emaila, błąd systemu. 1251 Nie wysłano emaila do tego subskrybenta, zablokowany administracyjnie