Specyfikacja API bramki SMS/MMS/IVR
|
|
- Bogna Wójcik
- 8 lat temu
- Przeglądów:
Transkrypt
1 Specyfikacja API bramki SMS/MMS/IVR wersja 1.5 Piotr Isajew 14 września 2011 c EXPERTUS,
2 Spis treści 1 Wprowadzenie Parametry konfiguracyjne Standardy kodowania Reprezentacja dat Postać komunikatów Komunikaty przesyłane od klienta do bramki Walidacja komunikatów Wysyłanie wiadomości SMS Wysyłanie wiadomości MMS Zapytanie o stan wysyłanej wiadomości Komunikaty przesyłane od bramki do klienta Odpowiedź na żądanie wysłania wiadomości Odpowiedź na zapytanie o stan wiadomości Dodatkowe uwagi Ograniczenia czasowe przy wysyłaniu wiadomości Dostarczanie potwierdzeń odebrania wiadomości Ograniczenie wielkości komunikatu Komunikacja dwukierunkowa Odbieranie odpowiedzi na wysłane wiadomości Obsługa wiadomości głosowych Zlecenie wysłania wiadomości TTS/IVR Wysyłanie prostej wiadomości TTS Zlecanie połączenia IVR Otrzymywanie informacji o połączeniu IVR Dostarczanie nagrania rozmowy Diagnostyka błędów Błędy o charakterze ogólnym Błędy o charakterze szczegółowym
3 5 Wykorzystanie do komunikacji poczty elektronicznej Błędy i retransmisje Zabezpieczenie komunikacji Komunikacja HTTP Komunikacja z użyciem poczty elektronicznej Przykłady Wysyłanie wiadomości SMS za pomocą programu wget Wysyłanie wiadomości SMS za pomocą PHP Odbiór wiadomości przychodzących za pomocą PHP Wysyłanie komunikatów do bramki za pomocą poczty elektronicznej Historia zmian Zmiany w wersji Zmiany w wersji
4 1. Wprowadzenie API działa w oparciu o proste komunikaty XML przekazywane za pomocą metody HTTP POST. Komunikaty XML mogą być również przekazywane za pomocą internetowej poczty elektronicznej. API umożliwia: wysyłanie wiadomości SMS z losowych numerów 9-cyfrowych wysyłanie wiadomości SMS z predefiniowanego numeru, w tym numeru alfanumerycznego (tzw. nadpis ) wysyłanie wiadomości MMS z losowych numerów 9-cyfrowych wysyłanie wiadomości głosowych w przypadku, gdy wiadomość SMS jest kierowana na numer stacjonarny otrzymywanie informacji o stanie wiadomości zleconych do wysłania otrzymywanie wiadomości SMS przesłanych w odpowiedzi na wiadomości wysłane z systemu wysyłanie wiadomości głosowych (TTS), oraz realizacja sesji IVR W zależności od wariantu podpisanej umowy nie wszystkie z powyższych funkcji mogą być dostępne. Domyślnie komunikacja z wykorzystaniem API jest jednokierunkowa transakcje są inicjowane przez klienta i potwierdzane synchronicznie przez bramkę. Przy tego typu dostępie nie ma możliwości odbierania odpowiedzi na wysłane SMSy. Na życzenie klienta istnieje możliwość skonfigurowania komunikacji dwukierunkowej, umożliwiającej asynchroniczne powiadamianie klienta o zmianie stanu wysyłanych wiadomości oraz otrzymywanie wiadomości SMS przesyłanych w odpowiedzi na wysłane wiadomości (patrz też 2.4). 1.1 Parametry konfiguracyjne Konfiguracja dostępu HTTP wymaga określenia dla klienta następujących parametrów: nazwa użytkownika i hasło klienta wykorzystywane do uwierzytelniania żądań. adres IP, z którego będą przesyłane żądania. Ponadto, jeśli dla klienta została aktywowana funkcja przekazywania potwierdzeń dostarczenia wiadomości lub odpowiedzi, konieczne jest określenie adresu URL po stronie klienta, na który będą przekazywane potwierdzenia dostarczenia wiadomości (por. 2.4). 3
5 W przypadku dostępu klient powinien określić adres poczty elektronicznej, który będzie obsługiwał komunikację z API. Dodatkowo skonfigurowanie dostępu będzie wymagało określenia parametrów, o których mowa w części Standardy kodowania Ilekroć w komunikatach API przekazywane są teksty, oczekuje się, że będą one kodowane z użyciem kodowania UTF Reprezentacja dat Jeżeli nie zostało jednoznacznie podane, że jest inaczej, wszystkie daty są podawane z wykorzystaniem czasu lokalnego dla bramki (CET/CEST). 4
6 2. Postać komunikatów Komunikaty przekazywane są w postaci obiektów XML, przekazywanych jako dane w metodzie HTTP POST na docelowy adres URL. 2.1 Komunikaty przesyłane od klienta do bramki Wszystkie komunikaty przekazywane od klienta do bramki mają następującą postać: <?xml version="1.0" encoding="utf-8"?> <gateway-request type="..."> <request-auth> <partnerlogin>testuser</partnerlogin> <partnerpassword>testpassword</partnerpassword> </request-auth> <request-data> </request-data> </gateway-request> Atrybut type określa rodzaj przesyłanego komunikatu, determinujący, jakie elementy mogą się pojawić w części request-data. Rodzaje przesyłanych komunikatów pokazane są w tablicy 2.1. Jeżeli żądanie POST przesłane do serwera nie zawiera komunikatu o podanej wcześniej postaci, przesyłany komunikat ma błędy składniowe, czy też dane uwierzytelniające nie są poprawne, to brama odpowiada komunikatem ERROR, po którym opcjonalnie następuje informacja o rodzaju błędu. Typ komunikatu sms-send-request mms-send-request ivr-send-request sms-status-request mms-status-request ivr-status-request Znaczenie żądanie wysłania wiadomości SMS żądanie wysłania wiadomości MMS żądanie wysłania wiadomści TTS/zainicjowania sesji IVR zapytanie o stan wiadomości SMS, których wysłanie zostało wcześniej zlecone zapytanie o stan wiadomości MMS, których wysłanie zostało wcześniej zlecone zapytanie o stan zleconego połączenia TTS/IVR Tablica 2.1: Komunikaty przesyłane od klienta 5
7 Komunikat sms-send-request sms-status-request mms-send-request mms-status-request Lokalizacja schematu Tablica 2.2: Lokalizacja schematów umożliwiających weryfikację przesyłanych dokumentów W przypadku, kiedy żądanie przesłane do bramki jest poprawne, bramka odpowiada komunikatem o postaci: <?xml version="1.0" encoding="utf-8"?> <gateway-response type="..."> </gateway-response> Element gateway-response zawiera elementy odnoszące się do poszczególnych elementów zawartych w części request-data, którego dotyczy odpowiedź. Atrybut type determinuje rodzaj elementów które zawarte są w odpowiedzi i obecnie może przyjmować następujące wartości: sms-send-response tj. odpowiedź dotyczy żądania wysłania SMSów sms-status-response tj. odpowiedź dotyczy zapytania o stan wcześniej wysłanych SMSów mms-send-response odpowiedź dotyczy żądanie wysłania MMSów, oraz mms-status-response odpowiedź dotyczy zapytania o stan wcześniej wysłanych MMSów ivr-send-response odpowiedź na zlecenie wysłania komunikatu IVR ivr-status-response odpowiedź dotyczy zapytania o stan zleceonego połączenia IVR Walidacja komunikatów Poprawność składniowa komunikatów przesyłanych od klienta do bramki może być zweryfikowana przy użyciu walidatora XML pozwalającego na walidację z użyciem schematów XML rekomendowanych przez W3C (xsd). Adresy, pod którymi opublikowano odpowiednie schematy zawiera tablica Wysyłanie wiadomości SMS W przypadku wysyłania wiadomości SMS żądanie gateway-request powinno być typu sms-sendrequest. Wówczas część request-data zawiera jeden lub więcej elementów sms-send-request, o postaci: <sms-send-request> <!-- elementy wymagane --> <message-id> </message-id> <msisdn> </msisdn> <sms-text>example of very simple send-request</sms-text> 6
8 <!-- elementy opcjonalne --> <dont-send-before> :00</dont-send-before> <tts-text>text</tts-text> <src-addr>test</src-addr> </sms-send-request> W żądaniu muszą wystąpić wszystkie elementy oznaczone jako elementy wymagane, a ponadto mogą wystąpić dowolne z elementów oznaczonych jako elementy opcjonalne. Znaczenie poszczególnych elementów jest następujące: message-id liczba naturalna jednoznacznie identyfikująca wiadomość w systemie klienta msisdn numer telefonu, na który ma być dostarczona wiadomość, w formacie lub sms-text treść wiadomości (dopuszcza się znaki z zestawu ASCII, oraz polskie znaki diakrytyczne) dont-send-before pozwala na wskazanie najwcześniejszego momentu, w którym system może wysłać wiadomość tts-text alternatywna treść wiadomości, którą należy odczytać przez system TTS jeżeli numer docelowy zostanie zidentyfikowany jako numer stacjonarny (maks znaków) src-addr wskazanie numeru, z którego ma zostać wysłana wiadomość (brak tego elementu jest tożsamy z wysłaniem wiadomości z dowolnego numeru 9-cyfrowego) Wysyłanie wiadomości MMS Postać komunikatu wykorzystywanego do wysłania wiadomości MMS zależy od sposobu jego definicji. Ogólna struktura żądania przedstawiona została poniżej: <mms-send-request> <message-id>4444</message-id> <msisdn> </msisdn> <message-template> <!-- specyfikacja szablonu wiadomości --> </message-template> <message-subject>temat</message-subject> <message-data> <!-- specyfikacja zawartości wiadomości --> </message-data> </mms-send-request> Szablon wiadomości System umożliwia wysyłanie wyłącznie wiadomości ze zdefiniowanym szablonem SMIL. Może to być jeden z szablonów zdefiniowanych w webowym interfejsie administracyjnym, bądź szablon zdefiniowany w treści MMS a. W przypadku użycia szablonu zdefiniowanego w interfejsie administracyjnym element message-template powinien zawierać identyfikator tego szablonu, np.: <message-template> <template-id>11</template-id> </message-template> 7
9 Możliwe jest również podanie treści szablonu SMIL bezpośrednio w komunikacie, np.: <message-template> <smil-data> <smil> <head> <layout> <region id="a" top="0" left="0" height="100%" fit="meet"/> </layout> </head> <body> <par> <img src="obrazek_1.jpg" region="a"/> </par> </body> </smil> </smil-data> </message-template> Oczekuje się, że w zdefiniowanym szablonie źródła poszczególnych elementów będą podane jako nazwy plików (bez katalogów) z rozszerzeniem odpowiadającym typom plików. Nazwy plików nie muszą odnosić się do istniejących plików w systemie klienta mają charakter wirtualny. Zawartość wiadomości Dla każdego z obiektów zdefiniowanych w szablonie SMIL w części message-data musi zostać określona zawartość tego obiektu. Zawartości poszczególnych obiektów określa się w odpowiadających im elementach message-part: <message-data> <message-part type="rodzaj specyfikacji" name="nazwa obiektu"> <!-- zawartość obiektu --> </message-part> </message-data> Atrybut name określa obiekt szablonu, którego dotyczy dany element message-part (np.: obrazek1.jpg). Nazwa powinna być podana jako nazwa pliku (bez ścieżki katalogów). Rozszerzenie powinno umożliwiać ustalenie typu MIME zawartości pliku. Atrybut type określa sposób określenia zawartości obiektu i może przyjmować następujące wartości: base64 zawartość binarna obiektu jest podana bezpośrednio wewnątrz elementu message-part kodowana zgodnie z base64. href wewnątrz elementu message-part znajduje się adres URL z pod którego można pobrać zawartość binarną obiektu text obiekt jest obiektem tekstowym i wewnątrz elementu message-part znajduje się treść tego obiektu System nie limituje w żaden sposób ilości oraz wielkości poszczególnych obiektów, należy jednak pamiętać, że całkowita wielkość jednej wiadomości MMS jest ograniczona do 280KB. 8
10 2.1.4 Zapytanie o stan wysyłanej wiadomości Zapytanie o stan wysłanej wiadomości powinno, w części request-data zawierać jeden lub więcej elementów sms-status-request, (lub mms-status-request) o postaci: <sms-status-request> <message-id> </message-id> </sms-status-request> gdzie message-id jest liczbą naturalną jednoznacznie identyfikującą wiadomość w systemie klienta. 2.2 Komunikaty przesyłane od bramki do klienta Wszystkie komunikaty przesyłane przez serwer do klienta mają postać: <?xml version="1.0" encoding="utf-8"?> <gateway-response type="..."> </gateway-response> Atrybut type determinuje zawartość elementów odpowiedzi. Może on obecnie przyjmować następujące wartości: sms-send-response oznacza, że gateway-response zawiera elementy typu sms-send-response sms-status-response oznacza, że gateway-response zawiera elementy typu sms-status-response mms-send-response zawiera odpowiedź na żądanie wysłania MMS a (mms-status-response) mms-status-response element gateway-response zawiera elementy mms-status-response status-notification jest używany przy powiadomieniach asynchronicznych; w tym przypadku element gateway-response może zawierać zarówno elementy mms-status-response jak i smsstatus-response Odpowiedź na żadanie wysłania wiadomości W odpowiedzi na żądanie wysłania wiadomości generowana jest odpowiedź typu sms-send-response, składająca się z elementów sms-send-response (analogicznie dla MMS i IVR) o postaci: <sms-send-response> <message-id>121212</message-id> <result>ok ERROR</result> </sms-send-response> Zawartość elementu result informuje o wyniku żądania wysłania w odniesieniu do danej wiadomości: OK oznacza, że wiadomość została przyjęta do wysłania ERROR oznacza, że wiadomość nie została zaakceptowana do wysłania; może to być wynikiem awarii systemu lub błędu w żądaniu wysłania wiadomości (np. brak wymaganych elementów, zła postać numeru, wykorzystanie id wykorzystanego wcześniej do wysłania innej wiadomości) 9
11 2.2.2 Odpowiedź na zapytanie o stan wiadomości Odpowiedź na zapytanie o stan wysłania wiadomości zawiera elementy sms-status-response (analogiczna sytuacja dla wiadomości MMS), o postaci: <gateway-response type="sms-status-response"> <sms-status-response> <message-id> </message-id> <part>0</part> <status>pending processing sent confirmed paused failed not found</status> <status-time>yyyy-mm-dd HH:MM</status-time> <sent-time>yyyy-mm-dd HH:MM</sent-time> <delivered-time>yyyy-mm-dd HH:MM</delivered-time> </sms-status-response> </gateway-response> Element part podaje numer kolejny części wiadomości (wartość istotna w przypadku gdy dochodzi do podziału wiadomości na części). Element status określa stan wiadomości. Dozwolone wartości: pending wiadomość została przyjęta przez system do wysłania ale jeszcze nie została wysłana processing jest podejmowana próba wysłania wiadomości sent wiadomość została wysłana do sieci GSM confirmed otrzymano potwierdzenie dostarczenia wiadomości paused administracyjnie wstrzymano przetwarzanie wiadomości przez system failed próba wysłania wiadomości zakończyła się niepowodzeniem i nie będą podejmowane kolejne próby wysłania tej wiadomości not found wiadomość o podanym message-id nie została znaleziona w systemie Elementy status-time, sent-time, delivered-time zawierają znaczniki czasowe dotyczące wiadomości. Ich znaczenie jest następujące: status-time określa moment ostatniej zmiany stanu wiadomości sent-time określa moment wysłania wiadomości delivered-time określa moment dostarczenia wiadomości do odbiorcy (w przypadku jeżeli wiadomość była wysłana z żądaniem potwierdzenia i otrzymano potwierdzenie) 2.3 Dodatkowe uwagi Ograniczenia czasowe przy wysyłaniu wiadomości W przypadku, jeżeli w żądaniu wysłania wiadomości nie wystąpi żadne graniczenie czasu, system, będzie próbował wysłać wiadomość od momentu przyjęcia zgłoszenia, do skutku lub wystąpienia nieodwracalnego błędu. Jeżeli w żądaniu ograniczenie dont-send-before ma wartość wcześniejszą niż moment wysyłania żądania, to jego wartość zostanie skorygowana na moment wysyłania żądania. 10
12 2.3.2 Dostarczanie potwierdzeń odebrania wiadomości System umożliwia wysyłanie wiadomości z żądaniem potwierdzenia ich dostarczenia. Należy przy tym zwrócić uwagę na to, że techniczna implementacja potwierdzenia zależy od sieci i telefonu odbiorcy wiadomości. W szczególności nie otrzymanie potwierdzenia pomimo żądania nie oznacza, że wiadomość nie została dostarczona do odbiorcy. Na życzenie klienta istnieje możliwość skonfigurowania komunikacji dwukierunkowej. Przy takiej konfiguracji system dostarcza powiadomienia o zmianie stanu poszczególnych wiadomości. Powiadomienia są wysyłane za pomocą metody HTTP POST na adres URL wskazany przez klienta. W treści żądania przesyłany jest komunikat gateway-response typu sms-status-response. W przypadku komunikacji dwukierunkowej dopuszczalna jest sytuacja, w której bramka wysyła do systemu klienta komunikat z potwierdzeniem tylko raz. W przypadku, gdy system klienta jest nieosiągalny lub komunikacja zostanie przerwana bramka nie ma obowiązku ponawiać próby przesłania potwierdzenia. System klienta powinien jednak móc obsłużyć sytuację, w której w ramach komunikatu gateway-response otrzyma potwierdzenie tej samej wiadomości więcej niż jeden raz Ograniczenie wielkości komunikatu Ze względów wydajnościowych, w komunikatach zawierających żądania przesyłane od klienta do bramki, wprowadzone jest odgórne ograniczenie ilości elementów zawartych w części request-data. Na dzień tworzenia niniejszego dokumentu to ograniczenie wynosi W przypadku przekroczenia tego ograniczenia, bramka odpowie komunikatem ERROR i całe żądanie zostanie nieprzetworzone. 2.4 Komunikacja dwukierunkowa Do skonfigurowania komunikacji dwukierunkowej konieczne jest podanie przez klienta adresu URL, na który bramka będzie przekazywać komunikaty. Bramka będzie wówczas przesyłać komunikaty opisane w 2.2 w treści żądania HTTP POST przesłanego na wskazany przez klienta adres. Jeżeli serwer HTTP obsługujący połączenie ze strony klienta wygeneruje w odpowiedzi kod HTTP 200, to uznaje się, że dane zostały dostarczone i ich transmisja nie będzie ponawiana Odbieranie odpowiedzi na wysłane wiadomości Przekazywanie do klienta odpowiedzi na wysłane wiadomości odbywa się poprzez użycie dodatkowego typu komunikatu gateway-response incoming-message. Komunikat gateway-response typu incoming-message zawiera elementy dla poszczególnych wiaodmości przychodzących. W ramach jednego komunikatu gateway-response mogą być przesyłane różne rodzaje wiadomości przychodzących. Obecnie mogą to być elementy: incoming-sms-message dla przychodzących wiadomości SMS incoming-ivr-message wysyłany w celu przekazania akcji wykonanych przez rozmówcę w trakcie sesji IVR Każdy z elementów tego komunikatu reprezentuje jedną wiadomość odebraną przez system i zawiera następujące elementy: message-id liczba naturalna jednoznacznie identyfikująca przekazywaną wiadomość w systemie SMS 11
13 msisdn numer telefonu, z którego odebrano wiadomość received-time moment odebrania wiadomości przez system SMS sms-text treść wiadomości 12
14 3. Obsługa wiadomości głosowych Począwszy od wersji 1.4 API obsługuje przesyłanie wiadomości głosowych z wykorzystaniem systemu IVR. Wiadomości tego typu mogą być przesyłane zarówno na numery komórkowe jak i stacjonarne w Polsce. System może być wykorzystany do wysyłania zarówno prostych komunikatów TTS (tj. odpowiednik wiadomości SMS) jak i do zlecania wykonania połączeń w ramach bardziej rozbudowanej komunikacji IVR. Ten drugi przypadek wymaga wcześniejszej konfiguracji odpowiedniego scenariusza IVR po stronie bramki. Dla sesji IVR możliwe jest otrzymywanie informacji o akcjach wykonanych przez rozmówcę (ściślej o ścieżce, przez którą przeszedł użytkownik w menu IVR), oraz nagrania z rozmowy. Dalsza treść tego rozdziału zakłada znajomość ogólnych zasad funkcjonowania API dla wiadomości SMS i MMS, zgodnie z ich opisem w rozdziale Zlecenie wysłania wiadomości TTS/IVR Zlecenie wysłania wiadomości IVR odbywa się poprzez przesłanie do bramki komunikatu gatewayrequest typu ivr-send-request. W skład elementów ivr-send-request wchodzą następujące elementy: message-id, msisdn, dont-send-before o znaczeniu takim samym jak dla innych komunikatów wysyłania wiadomości wykorzystywanych w API scenario-id opcjonalny identyfikator scenariusza IVR (przydzielany przez dostawcę) tts-argument argument tekstowy do wykorzystania przez syntetyzator mowy Wysyłanie prostej wiadomości TTS Przy wysyłaniu prostej wiadomości TTS należy: 1. Pominąć w komunikacie element scenario-id. 2. Podać dokładnie jeden element tts-argument. System zadzwoni na wskazany numer telefonu i odczyta treść komunikatu podanego w elemencie tts-argument. 13
15 3.1.2 Zlecanie połaczenia IVR W celu wykorzystania tej funkcji konieczne jest wcześniejsze skonfigurowanie przez dostawcę scenariusza IVR o charakterystyce uzgodnionej z klientem. Po skonfigurowaniu scenariusza dostawca przydziela identyfikator scenariusza, który należy przekazywać jako wartość elementu scenario-id w komunikacie ivr-send-request. W zależności od scenariusza komunikat może zawierać sekwencję jednego lub więcej elementów tts-argument, których treść jest odtwarzana przez syntetyzator mowy w ustalonych punktach scenariusza. 3.2 Otrzymywanie informacji o połaczeniu IVR W celu otrzymywania informacji o połączeniu IVR 1 konieczne jest przygotowanie przez klienta skryptu do odbierania komunikatów zgodnie z procedurą opisaną w części Nie ma możliwości uzyskania tych informacji poprzez wysyłanie do serwera zapytań ivr-status-request. Do klienta kierowane są wówczas komunikaty incoming-ivr-message zawierające następujące elementy: message-id liczba naturalna jednoznacznie identyfikująca wiadomość z punktu widzenia bramki IVR client-message-id liczba naturalna jednoznacznie identyfikująca wiadomość w systemie klienta (odpowiada wartości message-id w komunikacie ivr-send-request received-time moment odebrania wiadomości (tj. moment wykonania połączenia do klienta) ivr-path (element opcjonalny) węzły w systemie IVR przez które przeszedł użytkownik w trakcie rozmowy (w postaci NAZWA1->NAZWA2->...->NAZWAn, gdzie NAZWAn to nazwa n-tego węzła drzewa IVR w uzgodnionym scenariuszu) voice-recording (element opcjonalny) umożliwia przesyłanie nagrania rozmowy (więcej w p ) Dostarczanie nagrania rozmowy Informacje odnośnie nagrania połączenia są dostarczane w elemencie voice-recording. Sposób dostarczenia nagrania wynika z wartości atrybutu type elementu voice-recording. Obecnie jedyna dopuszczalna wartość tego atrybutu to base64 która oznacza, że nagranie dostarczone jest bezpośrednio jako wartość elementu voice-recording, jako dane WAV reprezentowane w kodowaniu Base64. W kolejnych wersjach API dopuszcza się wprowadzenie innych wartości atrybutu type, które będą się odnosić do innych sposobów dostarczania nagrania do systemu klienta. 1 Dotyczy wyłącznie zdefiniowanych scenariuszy IVR. Nie ma możliwości otrzymywania tej informacji dla prostych komunikatów TTS. 14
16 4. Diagnostyka błędów Błędy aplikacji lub przetwarzania danych są raportowane do systemu klienta na dwóch poziomach: ogólnym, oraz szczegółowym. 4.1 Błędy o charakterze ogólnym Błędy o charakterze ogólnym dotyczą następujących sytuacji: próba komunikacji z niedozwolonego adresu IP, lub przy użyciu niepoprawnych danych logowania niemożliwość poprawnej interpretacji całości komunikatu przesłanego do serwera (np. komunikat nie zawiera wymaganych elementów) błąd w oprogramowaniu API W przypadku wystąpienia błędu o charakterze ogólnym bramka odpowiada na żądanie HTTP POST klienta przesyłając komunikat tekstowy ERROR, po którym opcjonalnie, w nowej linii następuje treść informująca o charakterze błędu. Jeżeli z treści błędu nie wynika sposób postępowania w celu jego usunięcia i błąd ma charakter powtarzalny, należy skontaktować się z dostawcą celem ustalenia przyczyny i usunięcia błędu. 4.2 Błędy o charakterze szczegółowym Błędy o charakterze szczegółowym dotyczą poszczególnych elementów *-send-request komunikatu i są raportowane w odpowiednim elemencie *-send-response. W przypadku wystąpienia takiego błędu element result odpowiedniego komunikatu *-send-response będzie miał wartość ERROR. Dodatkowo w treści komunikatu może pojawić się dodatkowy element error zawierający dodatkowe informacje odnośnie charakteru błędu który wystąpił. Przykład: <gateway-response type="ivr-send-response"> <ivr-send-response> <message-id>21</message-id> <result>error</result> <error> <code>201</code> </error> </ivr-send-response> </gateway-response> 15
17 Kod Znaczenie 100 nieznana przyczyna wystąpienia błędu (w razie powtarzalnego występowania tego błędu prosimy o kontakt z działem technicznym w celu ustalenia przyczyny) trwałe odrzucenie żądania 200 nie należy ponawiać próby wysłania, brak bardziej szczegółowych informacji o przyczynach odrzucenia 201 nieprawidłowy adres docelowy (np. numer telefonu) 202 nieprawidłowy adres źródłowy (np. próba wysłania wiadomości z nadpisu, który nie został aktywowany dla danego klienta) 203 treść wiadomości zawiera niedozwolone znaki 204 przekroczona dozwolona ilość znaków w treści wiadomości 205 nieprawidłowa wartość elementu campaign-id 206 przekroczony rozmiar wiadomości (dla wiadomości MMS) 207 ponowna próba wysłania wiadomości z tym samym id 210 typ wiadomości nie dozwolony dla danego klienta 220 w treści żądania brak parametru wymaganego do zrealizowania zlecenia tymczasowe odrzucenie wiadomości 300 brak szczegółowych informacji o przyczynach odrzucenia, można ponowić próbę wysłania w późniejszym terminie 301 przekroczony miesięczny limit wysyłanych wiadomości, prosimy skoncentrować się z działem sprzedaży w celu zwiększenia limitu Tablica 4.1: Wykaz kodów błędów wykorzystywanych przez XML API W ramach elementu error występuje zawsze element code zawierający liczbowy kod informujący o rodzaju błędu. Dodatkowo może wystąpić element info zawierający tekstowy opis przyczyny wystąpienia błędu. Kod błędu jest trzycyfrową liczbą dodatnią. W zależności od wartości kodu, błąd może mieć charakter przejściowy (tj. wystąpienie błędu nie oznacza, że ponowne próby wysłania tej samej wiadomości w niezmienionej postaci również zakończy się błędem), lub ostateczny (tj. kolejna próba wysłania tej samej, niezmienionej wiadomości, również zostanie odrzucona). Błędy, które mają charakter tymczasowy, to błędy, których najbardziej znacząca cyfra kodu błędu to 3. Wszystkie pozostałe błędy mają charakter ostateczny. Szczegółowa lista kodów wraz z ich znaczeniem została przedstawiona w tablicy 4.1. Pozostałe wartości kodów są zarezerwowane do użycia w przyszłości i ich wystąpienie należy traktować jak wystąpienie błędu ostatecznego (za wyjątkiem kodów 3xx). 16
18 5. Wykorzystanie do komunikacji poczty elektronicznej Na życzenie klienta może zostać skonfigurowany dostęp do API wykorzystujący, jako nośnik komunikatów API, internetową pocztę elektroniczną. Postać wykorzystywanych komunikatów jest zgodna z opisem zamieszczonym w rozdziale 2. Jeżeli wykorzystywany jest ten rodzaj dostępu, komunikaty API powinny być przekazywane w treści wiadomości pocztowych przesyłanych między ustalonymi adresami poczty elektronicznej systemu i klienta. Treść wiadomości nie powinna zawierać żadnych dodatkowych elementów poza komunikatem XML i podpisem cyfrowym. Temat wiadomości nie jest istotny (jest ignorowany). API przesyła komunikaty do klienta z pustym polem tematu. W celu uruchomienia dostępu z wykorzystaniem poczty elektronicznej klient powinien podać adres e- mail, z którego będą przesyłane komunikaty do API. System klienta powinien być skonfigurowany w taki sposób, żeby wiadomości przesyłane przez API na ten adres były w sposób poprawny odbierane. Ponadto, dla tego rodzaju dostępu wymagane jest zabezpieczenie komunikacji zgodnie z regułami określonymi na stronie??. 5.1 Błędy i retransmisje Ponieważ komunikacja z wykorzystaniem poczty elektronicznej ma charakter asynchroniczny, należy wziąć pod uwagę, że opóźnienia w przekazywaniu potwierdzeń do klienta mogą być rzędu pojedynczych minut. Dlatego ewentualne retransmisje wiadomości, których wysłanie zostało zlecone API, ale dla których klient nie otrzymał komunikatu potwierdzającego przyjęcie przez API, powinny odbywać się w rozsądnych, uwzględniających bezwładność poczty elektronicznej, interwałach czasowych. Nie wydaje się, żeby interwały krótsze niż 30 minut były w tym przypadku uzasadnione. API nigdy nie oczekuje potwierdzenia komunikatów przesłanych na adres poczty elektronicznej systemu klienta. Ewentualne retransmisje, w przypadku zakłócenia komunikacji na poziomie IP, odbywają się zgodnie ze specyfikacją protokołu SMTP. Klient odpowiada za takie skonfigurowanie swojego systemu pocztowego, żeby komunikaty dostarczone przez API były poprawnie odbierane. 17
19 6. Zabezpieczenie komunikacji 6.1 Komunikacja HTTP W celu zabezpieczenia komunikacji dostęp do bramki będzie możliwy tylko za pośrednictwem tunelu IPsec. W związku z tym w celu udostępnienia połączenia konieczne będzie określenie przez klienta adresu IP zakończenia tunelu po stronie klienta, oraz skonfigurowanie firewalla i routingu w taki sposób, żeby był możliwy dostęp do bramki SMS. 6.2 Komunikacja z użyciem poczty elektronicznej W przypadku gdy dostęp do API odbywa się z wykorzystaniem poczty elektronicznej wymagane jest zabezpieczenie komunikacji poprzez podpisanie cyfrowe komunikatu API (dokumentu XML) za pomocą PGP. Podpis powinien być weryfikowalny przy użyciu klucza publicznego przekazanego do dostawcy na etapie konfiguracji usługi. Podpis powinien być wykonany przy użyciu klucza wygenerowanego dla adresu , z którego wysłano komunikat API. Obecna wersja API nie obsługuje standardu PGP/Mime. Podpisy cyfrowe powinny być składane bezpośrednio w treści wiadomości . Podpisy na komunikatach wysyłanych przez bramkę są weryfikowalne przy użyciu klucza publicznego opublikowanego pod adresem Na życzenie klienta komunikaty mogą być szyfrowane przy użyciu PGP. 18
20 7. Przykłady Niniejszy rozdział zawiera przykłady związane z testowaniem i integracją API. Dla uproszczenia i maksymalnej przejrzystości przykłady nie zawierają żadnej obsługi błędów. W przykładach, które tego wymagają nie uwzględniono również specjalnego kodowania znaków specjalnych, które mogą się pojawić w treści SMS a podczas rzeczywistej eksploatacji. Autorzy rozwiązań bazujących na przykładach z tego rozdziału powinni wziąć powyższe pod uwagę. 7.1 Wysyłanie wiadomości SMS za pomoca programu wget Do przesłania bramce SMS żądania wykorzystującego API można się posłużyć programami takimi jak wget czy curl. Na przykład polecenie: wget -O- -q --post-file=req.xml powoduje przesłanie do serwisu testowego bramki żądania zawartego w pliku req.xml, i wypisanie na standardowym wyjściu odpowiedzi bramki. Jeżeli plik req.xml ma postać: <?xml version="1.0" encoding="utf-8"?> <gateway-request type="sms-send-request"> <request-auth> <partnerlogin>test</partnerlogin> <partnerpassword>test</partnerpassword> </request-auth> <request-data> <sms-send-request> <message-id>5</message-id> <msisdn> </msisdn> <sms-text>przykladowy sms</sms-text> </sms-send-request> </request-data> </gateway-request> to przykładowa odpowiedź systemu będzie miała postać: <?xml version="1.0" encoding="utf-8" standalone="no"?> <gateway-response type="sms-send-response"> <sms-send-response> <message-id>5</message-id> <result>ok</result> </sms-send-response> </gateway-response> Co oznacza, że system przyjął wiadomość i będzie podejmował próby jej wysłania. 19
Specyfikacja API bramki SMS/MMS/TTS
Specyfikacja API bramki SMS/MMS/TTS wersja 1.3.1 Piotr Isajew (pki@ex.com.pl) 21 lutego 2011 c 2011 EXPERTUS, http://www.ex.com.pl 1. Wprowadzenie API działa w oparciu o proste komunikaty XML przekazywane
Bardziej szczegółowoSpecyfikacja API bramki SMS/MMS/IVR
Specyfikacja API bramki SMS/MMS/IVR wersja 1.4 Piotr Isajew (pki@ex.com.pl) 13 kwietnia 2011 c 2011 EXPERTUS, http://www.ex.com.pl Spis treści 1 Wprowadzenie 3 1.1 Parametry konfiguracyjne................................
Bardziej szczegółowoDokumentacja smsapi wersja 1.4
Dokumentacja smsapi wersja 1.4 1. Wprowadzenie Platforma smsapi została skierowana do użytkowników chcących rozbudować swoje aplikacje o system wysyłania smsów. Aplikacja ta w prosty sposób umożliwia integrację
Bardziej szczegółowoSpecyfikacja HTTP API. Wersja 1.6
Specyfikacja HTTP API Wersja 1.6 1. Wprowadzenie Platforma PlaySMS umożliwia masową rozsyłkę SMS-ów oraz MMS-ów marketingowych. Umożliwiamy integrację naszej platformy z dowolnym systemem komputerowym
Bardziej szczegółowoSpecyfikacja wysyłek marketingowych v1.10
Specyfikacja wysyłek marketingowych v1.10 1 Historia zmian: Al. Jerozolimskie 81 Data Autor Opis 05-07-2013 Olga Krygier-Zawistowska Dodano przykład w PHP 2 Specyfikacja komunikacji Al. Jerozolimskie 81
Bardziej szczegółowoDOKUMENTACJA TECHNICZNA SMS API MT
DOKUMENTACJA TECHNICZNA SMS API MT Mobitex Telecom Sp.j., ul. Warszawska 10b, 05-119 Legionowo Strona 1 z 5 Ten dokument zawiera szczegółowe informacje odnośnie sposobu przesyłania requestów do serwerów
Bardziej szczegółowoDokumentacja interfejsu HTTPD. Platforma BSMS.PL Instrukcja podłączenia po przez http
Dokumentacja interfejsu HTTPD Platforma BSMS.PL Instrukcja podłączenia po przez http Dokumentacja interfejsu httpd (strona 2) SPIS TREŚCI 1. Zawartość dokumentu str.3 2. Informacje ogólne 2.1 Zastosowanie
Bardziej szczegółowoGatesms.eu Mobilne Rozwiązania dla biznesu
Mobilne Rozwiązania dla biznesu SPECYFIKACJA TECHNICZNA WEB API-USSD GATESMS.EU wersja 0.9 Opracował: Gatesms.eu Spis Historia wersji dokumentu...3 Bezpieczeństwo...3 Wymagania ogólne...3 Mechanizm zabezpieczenia
Bardziej szczegółowoSpecyfikacja instalacji usługi SMS Premium w Przelewy24.pl
Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl wersja.2.9 data 2014-11-21 Opis usług: P24 KOD P24 KLUCZ P24 WAPA SEND SMS Strona 1 z 8 P24 KOD Przebieg transakcji Operacje po stronie Sprzedawcy
Bardziej szczegółowoSpis 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 - Email 7.
V 1.1 2008 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 - Email 7. Sprawdzanie stanu konta 1. Założenia ogólne PowiadomieniaSMS.pl
Bardziej szczegółowoSpecyfikacja techniczna. mprofi Interfejs API
Warszawa 09.04.2015. Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 1 Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 WERSJA DATA STATUTS AUTOR 1.0.0 10.03.2015 UTWORZENIE DOKUMENTU
Bardziej szczegółowoFunkcje dodatkowe. Wersja 1.2.1
Funkcje dodatkowe Wersja 1..1 Dokumentacja SMSAPI (https) FUNKCJE DODATKOWE z dnia 1.06.01 Wersja 1..1 SPIS TREŚCI 1.Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją dla funkcji zarządzania kontem
Bardziej szczegółowoFunkcje dodatkowe. Wersja 1.2.1
Funkcje dodatkowe SPIS TREŚCI 1.Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją dla funkcji zarządzania kontem 1.2 Adresy URL do połączenia z aplikacją dla funkcji zarządzania polami nadawcy I. ZARZĄDZANIE
Bardziej szczegółowoDokumentacja techniczna API systemu SimPay.pl
Wprowadzenie Dokumentacja techniczna API systemu SimPay.pl Wersja 1.0 z dnia 24.03.2015 r. API serwisu SimPay.pl opiera się o danych wysyłanych i zwracanych w formie JSON. W przypadku napotkania jakiegokolwiek
Bardziej szczegółowoAPI transakcyjne BitMarket.pl
API transakcyjne BitMarket.pl Wersja 20140402 1. Sposób łączenia się z API... 2 1.1. Klucze API... 2 1.2. Podpisywanie wiadomości... 2 1.3. Parametr tonce... 2 1.4. Limity zapytań... 3 1.5. Odpowiedzi
Bardziej szczegółowoSpecyfikacja interfejsów usług Jednolitego Pliku Kontrolnego
a. Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego Ministerstwo Finansów Departament Informatyzacji 23 May 2016 Version 1.3 i Spis treści 1 Przygotowanie danych JPK... 3 1.1 Przygotowanie
Bardziej szczegółowoBRAMKA HTTP SMS XML Dokumentacja techniczna. wersja 3.32
BRAMKA HTTP SMS XML Dokumentacja techniczna wersja 3.32 autor: Michał Jastrzębski ostatnia aktualizacja : 27.05.2015 Historia zmian Data Osoba Opis zmian 2006-12-01 Marcin Mańk Pierwsza wersja 2007-08-20
Bardziej szczegółowoDOKUMENTACJA TECHNICZNA KurJerzyAPI wersja 1.0
KurJerzyAPI wersja 1.0 Spis treści Wstęp...3 1. Korzystanie z interfejsu KurJerzyAPI...4 1.1 Warunki korzystania z interfejsu...4 1.2 Zabezpieczenia interfejsu...4 2. Specyfikacja interfejsu KurJerzyAPI...6
Bardziej szczegółowoDokumentacja REST API v 3.0. Kraków, 7 marca FreshMail, ul. Fabryczna 20a, Kraków tel , freshmail.
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 ,
Bardziej szczegółowoZasady budowy i przekazywania komunikatów XML w systemie kdpw_otc
Warszawa, 07 lutego 2013 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.2 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...
Bardziej szczegółowoZasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP
Załącznik Nr 3 KDPW_CCP Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP Wersja 1.0 Warszawa, czerwiec 2012 Spis treści Wstęp... 3 Budowa komunikatów XML... 3 Przestrzenie
Bardziej szczegółowoZasady budowy i przekazywania komunikatów XML w systemie kdpw_otc
Warszawa, 09 grudnia 2014 Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc Wersja 1.4.3 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw (namespaces)...
Bardziej szczegółowoDokumentacja interfejsu Webservices API. Wersja 2.0 [12 stycznia 2014] http://bramka.gsmservice.pl e-mail: bramka@gsmservice.pl
http://bramka.gsmservice.pl e-mail: bramka@gsmservice.pl Bramka SMS: Obsługiwanych ponad 700 sieci w ponad 200 krajach Świata SMSy z własnym polem nadawcy Raporty doręczeń Obsługa długich wiadomości SMS
Bardziej szczegółowoOPIS TECHNICZNY SYSTEM HOSTED SMS
OPIS TECHNICZNY SYSTEM HOSTED SMS Wersja 1.6.2 Warszawa, lipiec 2015 1 SPIS TREŚCI 1. Wprowadzenie... 3 2. Podstawowe Parametry systemu Hosted SMS... 3 Dostępność... 3 Definicja znaków i długości wiadomości
Bardziej szczegółowoZasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP
Warszawa, lipiec 2012 Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP Wersja 1.1 1 Spis treści Tabela zmian... 3 Wstęp... 4 Budowa komunikatów XML... 4 Przestrzenie nazw
Bardziej szczegółowoSystem DiLO. Opis interfejsu dostępowego v. 2.0
System DiLO Opis interfejsu dostępowego v. 2.0 Warszawa 2015 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie możliwości przejścia z wydania karty w POZ (WK-POZ) do zabiegu operacyjnego (ZAB-OPER)
Bardziej szczegółowoDokumentacja SMS przez FTP
Dokumentacja SMS przez FTP 1 Wprowadzenie... 2 Właściwości plików... 3 Tworzenie konfiguracji w Panelu Klienta... 4 Raporty doręczeń... 5 Historia zmian... 6 2 Wprowadzenie Usługa wysyłki SMS przez FTP
Bardziej szczegółowoDokumentacja SMPP API
Dokumentacja SMPP API 1 Wprowadzenie... 2 Połączenie z SMPP API... 3 Informacje ogólne... 4 Dostępne tryby bindowania... 5 Komendy SMPP... 6 Raporty doręczeń... 7 Kody błędów... 8 Statusy wiadomości...
Bardziej szczegółowoMINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP
MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...
Bardziej szczegółowoDokumentacja REST API v 3.0
Dokumentacja REST API v 3.0 Kraków, 16 kwietnia 2012 FreshMail, ul. Fabryczna 20a, 31-553 Kraków tel. +48 12 617 61 40, info@freshmail.pl, freshmail.pl Spis treści Opis API... 3 Uwierzytelnienie... 3 Odpowiedzi
Bardziej szczegółowoInstrukcja konfiguracji funkcji skanowania
Instrukcja konfiguracji funkcji skanowania WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_PL 2004. Wszystkie prawa zastrzeżone. Rozpowszechnianie bez zezwolenia przedstawionych materiałów i informacji
Bardziej szczegółowoDokumentacja REST API v 3.0
Dokumentacja REST API v 3.0 Kraków, 26 kwietnia 2012 FreshMail, ul. Fabryczna 20a, 31-553 Kraków tel. +48 12 617 61 40, info@freshmail.pl, freshmail.pl Spis treści Opis API... 3 Uwierzytelnienie... 3 Odpowiedzi
Bardziej szczegółowoSpis treści INTERFEJS (WEBSERVICES) - DOKUMENTACJA TECHNICZNA 1
I N T E R F E J S W E BSERVICES NADAWANIE PAKIETÓW D O S Y S T EMU MKP PRZEZ I N TERNET D O K U M E N T A C J A T E C H N I C Z N A P A Ź D Z I E R N I K 2 0 1 6 Spis treści 1. Wstęp... 2 2. Informacje
Bardziej szczegółowoPrzykładowa integracja systemu Transferuj.pl
Krajowy Integrator Płatności Spółka Akcyjna z siedzibą w Poznaniu, przy ul. Św. Marcin 73/6, wpisana do rejestru przedsiębiorców Krajowego Rejestru Sądowego prowadzonego przez Sąd Rejonowy Poznań Nowe
Bardziej szczegółowoDokumentacja API BizIn
Dokumentacja API BizIn Spis treści Wstęp... 1 Dostęp do API BizIn... 1 Identyfikatory API... 1 Dostępne akcje... 3 Przykład wywołania API w języku PHP... 3 Pobieranie danych... 3 Wystawianie dokumentu
Bardziej szczegółowoDokumentacja techniczna - PBL
Dokumentacja techniczna - PBL Spis treści 1. Wprowadzenie... 2 2. Formularz płatności... 2 3. Rejestracja konta w HotPay... 3 4. Rejestracja serwisu... 4 5. Pojedyncza płatność... 5 5.1 Konfiguracja serwisu...
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu Zen Cart 1.3.9 1.5
Wdrożenie modułu płatności eservice dla systemu Zen Cart 1.3.9 1.5 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Bardziej szczegółowoDokumentacja techniczna SMS MO
Dokumentacja techniczna SMS MO Spis Treści 1. Wprowadzenie 2 1.1. Przebieg płatności Premium SMS 2 1.2. Weryfikacja płatności..3 2. Weryfikacja poprawności kodu aktywacyjnego...3 3. Przykład użycia zapytania
Bardziej szczegółowoSMS Kod Automatyczny
Dokumentacja 2.0.0 SMS Kod Automatyczny Dokumentacja dla SMS Kod Automatyczny Web Service REST CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax: +48 032 764-18-40
Bardziej szczegółowoDokumentacja interfejsu MySQL. Platforma BSMS.PL Instrukcja podłączenia po przez mysql
Dokumentacja interfejsu MySQL Platforma BSMS.PL Instrukcja podłączenia po przez mysql Dokumentacja interfejsu mysql (strona 2) SPIS TREŚCI 1. Zawartość dokumentu str.3 2. Informacje ogólne 2.1 Zastosowanie
Bardziej szczegółowoDOKUMENTACJA INTERFEJSU MY MYSQL. Platforma SMeSKom instrukcja podłączenia poprzez mysql Protokół w wersji 2.0
DOKUMENTACJA INTERFEJSU MY MYSQL Platforma SMeSKom instrukcja podłączenia poprzez mysql Protokół w wersji 2.0 Autor smeskom@smeskom.pl Data 2008-08-21 Wersja 2.0 rev.1 Spis treści Dokumentacja interfejsu
Bardziej szczegółowoDokumentacja 2SMS
Dokumentacja Email2SMS 1 Wprowadzenie... 2 Tworzenie uprawnionego adresu email oraz klucza... 3 Bezpieczeństwo... 4 Wysyłanie wiadomości SMS... 5 Historia zmian... 8 2 Wprowadzenie SerwerSMS.pl umożliwia
Bardziej szczegółowoMinisterstwo Finansów
Ministerstwo Finansów Departament Informatyzacji Specyfikacja Wejścia-Wyjścia Wersja 1.0 Warszawa, 16.02.2017 r. Copyright (c) 2017 Ministerstwo Finansów MINISTERSTWO FINANSÓW, DEPARTAMENT INFORMATYZACJI
Bardziej szczegółowoProcedura Walidacyjna Interfejs
Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.
Bardziej szczegółowoDOKUMENTACJA INTERFEJSU MY MYSQL. Platforma SMeSKom instrukcja podłączenia poprzez mysql Protokół w wersji 3.1
DOKUMENTACJA INTERFEJSU MY MYSQL Platforma SMeSKom instrukcja podłączenia poprzez mysql Protokół w wersji 3.1 Autor smeskom@smeskom.pl Data 16.06.2009 Wersja 3.1 rev.1 Spis treści Dokumentacja interfejsu
Bardziej szczegółowoDokumentacja Techniczna SMS MO
Dokumentacja Techniczna SMS MO SMS PREMIUM MO KOD AUTOMATYCZNY EPŁATNOŚCI SP. Z O.O. SP. K. UL. 27 STYCZNIA 9 34-120 ANDRYCHÓW SPIS TREŚCI 1. Wprowadzenie... 2 1.1 Schemat przebiegu płatności w modelu
Bardziej szczegółowoSpecyfikacja API 1.0. Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST
Specyfikacja API 1.0 API REST Specyfikacja kontroli Konta systemu CashBill z wykorzystaniem API opartego na REST CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42
Bardziej szczegółowoAPI przekazy masowe - Dokumentacja. v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/ Poznań.
API przekazy masowe - Dokumentacja v 1.1, czerwiec 2014 KIP S.A. ul. Św. Marcin 73/6 61-808 Poznań www.kipsa.pl www.tpay.com 1 Bramka API Dokumentacja opisuje możliwość wykonania przekazów masowych za
Bardziej szczegółowoPrzykładowa integracja systemu tpay.com KIP S.A. ul. Św. Marcin 73/ Poznań.
KIP S.A. ul. Św. Marcin 73/6 61-808 Poznań www.kipsa.pl www.tpay.com 1 Przesyłanie parametrów transakcji Poniżej przedstawiono kod przykładowej strony HTML, której zadaniem jest przekierowanie klienta
Bardziej szczegółowoInstrukcja korzystania z usługi EMAIL2SMS. Wersja 2.0 [12 stycznia 2014] http://bramka.gsmservice.pl e-mail: bramka@gsmservice.pl
http://bramka.gsmservice.pl e-mail: bramka@gsmservice.pl Bramka SMS: Obsługiwanych ponad 700 sieci w ponad 200 krajach Świata SMSy z własnym polem nadawcy Raporty doręczeń Obsługa długich wiadomości SMS
Bardziej szczegółowoPHP: bloki kodu, tablice, obiekty i formularze
1 PHP: bloki kodu, tablice, obiekty i formularze SYSTEMY SIECIOWE Michał Simiński 2 Bloki kodu Blok if-else Switch Pętle Funkcje Blok if-else 3 W PHP blok if i blok if-else wyglądają tak samo i funkcjonują
Bardziej szczegółowoZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja
ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.
Bardziej szczegółowoINSTRUKCJA OBSŁUGI PANELU ADMINISTRACYJNEGO MÓJ DOTPAY v0.1
Dział Pomocy Technicznej Dotpay ul. Wielicka 72 30-552 Kraków Tel. +48 126882600 Faks +48 126882649 E-mail: tech@dotpay.pl INSTRUKCJA OBSŁUGI PANELU ADMINISTRACYJNEGO MÓJ DOTPAY v0.1 Przyjmowanie płatności
Bardziej szczegółowoWarszawa Specyfikacja techniczna. mprofi Interfejs API wersja 1.0.7
Warszawa 03.11.2015. Specyfikacja techniczna mprofi Interfejs API wersja 1.0.7 WERSJA DATA STATUTS AUTOR 1.0.0 10.03.2015 UTWORZENIE DOKUMENTU PAWEŁ ANDZIAK 1.0.1 23.03.2015 MODYFIKACJA MAREK SZWAŁKIEWICZ
Bardziej szczegółowoBezpieczne Zakupy. - specyfikacja techniczna implementacji uproszczonej
Bezpieczne Zakupy - specyfikacja techniczna implementacji uproszczonej P OL C AR D is a regis t e r e d t ra d e ma rk o f FI R S T D AT A P O L S K A S. A., FI RS T D AT A P O L S K A S. A., Al. J e roz
Bardziej szczegółowoAukcja trwa od momentu, gdy informacje o przedmiocie są dostępne dla klientów, a kończy się wraz z wysłaniem opisanego dalej komunikatu FINISH_MSG.
Jan Inowolski - ji262511 Protokół komunikacji YouPAY! Wersja 1 Spis treści: * Streszczenie * Cele * Model komunikacji * Założenia * Format komunikatów * Pomocnicze typy danych * Komunikaty specjalne *
Bardziej szczegółowoDOKUMENTACJA IMPLEMENTACJI MECHANIZMÓW OBSŁUGI AHMES SMS (soap) 2013-03-24
Ahmes Sp. z o.o. ul. Lewicka 13/15 02-547 Warszawa tel: (22) 113 10 00, fax: (22) 203 63 21, e-mail: biuro@ahmes.pl, http://www.ahmes.pl DOKUMENTACJA IMPLEMENTACJI MECHANIZMÓW OBSŁUGI AHMES SMS (soap)
Bardziej szczegółowoPłatności CashBill - SOAP
Dokumentacja techniczna 1.0 Płatności CashBill - SOAP Dokumentacja wdrożenia systemu Płatności CashBill w oparciu o komunikację według protokołu SOAP CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa
Bardziej szczegółowoDokumentacja interfejsu API
http://postivo.pl Dokumentacja interfejsu API wersja 1.14 [20 marca 2015] Dokumentacja API Postivo.pl ver. 1.14 [20.03.2015] str. 2 Spis treści 1. Historia zmian w dokumentacji... 4 2. Wprowadzenie...
Bardziej szczegółowoAPI transakcji - Dokumentacja. v 2. 2, marzec 2017 KIP S.A. ul. Św. Marcin 73/ Poznań.
API transakcji - Dokumentacja v 2. 2, marzec 2017 KIP S.A. ul. Św. Marcin 73/6 61-808 Poznań www.kipsa.pl www.tpay.com 1 Bramka API Dokumentacja opisuje możliwość stworzenia transakcji oraz pobrania jej
Bardziej szczegółowoGatesms.eu Mobilne Rozwiązania dla biznesu
SPECYFIKACJA TECHNICZNA WEB XML-API GATESMS.EU wersja 1.2 Gatesms.eu Spis Historia wersji dokumentu... 3 Bezpieczeństwo... 3 Wymagania ogólne... 3 Mechanizm zabezpieczenia transmisji HTTP...3 Zasady ogóle...
Bardziej szczegółowoWdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6
Wdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6 Wersja 03 Styczeń 2016 Centrum Elektronicznych Usług Płatniczych eservice Sp. z o.o. Spis treści 1. Wstęp... 3 1.1. Przeznaczenie dokumentu...
Bardziej szczegółowoImplementacja mechanizmu SkyCashClick Wersja 0.1
Implementacja mechanizmu SkyCashClick Wersja 0.1 SkyCash 1/6 Spis treści: 1. Opis usługi... 3 2. Osadzenie przycisku SkyCashClick... 4 2.1. Parametry transakcji... 4 2.2. Weryfikacja znacznika parametrów
Bardziej szczegółowoDotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE
Warszawa, 16.07.2013r. Nabywca: Rezerweo Sp. z o.o. Ul. Tamka38 00-355 Warszawa Tel./fax 22 556 23 42 e-mail: dariusz.urbanski@rezerweo.com Dane oferenta: ZAPYTANIE OFERTOWE W zawiązku z realizacją projektu
Bardziej szczegółowoPołączenie Partnera z serwisem JustPay poprzez - METODĘ 2
Połączenie Partnera z serwisem JustPay poprzez - METODĘ 2 Generowanie kodów: po stronie Partnera Weryfikacja kodów: po stronie Partnera Spis treści 1. Kolejne kroki w stworzeniu własnego serwisu 2. Jak
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu oscommerce 2.3.x
Wdrożenie modułu płatności eservice dla systemu oscommerce 2.3.x - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu Gekosale 1.4
Wdrożenie modułu płatności eservice dla systemu Gekosale 1.4 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do integracji...
Bardziej szczegółowoZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI
PROJEKT: ZAPROJEKTOWANIE, WYKONANIE I WDROŻENIE SYSTEMU INFORMATYCZNEGO OBSŁUGUJĄCEGO E-PŁATNOŚCI ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI Strona 1 z 19 Informacje o Historia zmian Wprowadzenie
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9
Wdrożenie modułu płatności eservice dla systemu Magento 1.4 1.9 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do
Bardziej szczegółowoDokumentacja techniczna SMS MO
Dokumentacja techniczna SMS MO SMS PREMIUM MO KOD AUTOMATYCZNY Autor: Mirosław Pietrzak LEADERS SP. Z O.O. SP. K. BIURO@LEADERS.NET.PL Spis treści 1. Wprowadzenie... 2 1.1 Schemat przebiegu płatności w
Bardziej szczegółowoRemote Quotation Protocol - opis
Remote Quotation Protocol - opis Michał Czerski 20 kwietnia 2011 Spis treści 1 Streszczenie 1 2 Cele 2 3 Terminologia 2 4 Założenia 2 4.1 Połączenie............................... 2 4.2 Powiązania z innymi
Bardziej szczegółowoWdrożenie modułu płatności eservice. dla systemu PrestaShop 1.3-1.6
Wdrożenie modułu płatności eservice dla systemu PrestaShop 1.3-1.6 - dokumentacja techniczna Wer. 02 Warszawa, lipiec 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Bardziej szczegółowoSYSTEM INFORMATYCZNY KS-SEW
DOKUMENTACJA TECHNICZNA KAMSOFT S.A. 40-235 Katowice ul. 1-Maja 133 Tel. (032) 2090705, Fax. (032) 2090715 http:www.kamsoft.pl, e-mail: 5420@kamsoft.pl SYSTEM INFORMATYCZNY NR KATALOGOWY 2334PI06.00 WYDANIE
Bardziej szczegółowoSpecyfikacja raportowania dla partnerów
Specyfikacja raportowania dla partnerów Wersja dokumentu: 02.05.02 2018.05.17 Specyfikacja raportowania 1. Opis ogólny Wprowadzenie trackingu (mechanizmu zapisywania generowanego ruchu i wniosków) jest
Bardziej szczegółowoAutomater.pl zdalne tworzenie i zarządzanie transakcjami dokumentacja API wersja 0.1
Dokumentacja API 0.1 Automater.pl zdalne tworze i zarządza transakcjami dokumentacja API wersja 0.1 Automater sp. z o.o., ul. Belgradzka 4/42, 02-793 Warszawa 2 1. Wstęp System Automater.pl udostępnia
Bardziej szczegółowoBaza numerów Wersja 1.1
Baza numerów Wersja 1.1 SPIS TREŚCI 1. Wprowadzenie 1.1 Adresy URL do połączenia z aplikacją 1.2 Informacje zwrotne wysyłane z API w odpowiedzi na odebrane odwołania I. Zarządzanie grupami Bazy Numerów
Bardziej szczegółowoPayPo API v.2.0. Dokument zawiera specyfkaccę techniczną REST API PayPo.pl w wersci 2.0. Wersja dokumentu. Wykaz zmian
PayPo API v.2.0 Dokument zawiera specyfkaccę techniczną REST API PayPo.pl w wersci 2.0. Wersja dokumentu Data Wykaz zmian 1.2.2 2017.12.12 Rozszerzenie funkcconalności atrybutu zaufanego klienta 1.2.1
Bardziej szczegółowoSpecyfikacja Techniczna 2.0. Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode
Specyfikacja Techniczna 2.0 PayCode API Specyfikacja techniczna usługi dystrybucji kodów dostępowych PayCode CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:
Bardziej szczegółowoPGP - Pretty Good Privacy. Użycie certyfikatów niekwalifikowanych w programie PGP
PGP - Pretty Good Privacy Użycie certyfikatów niekwalifikowanych w programie PGP Spis treści: Wstęp...3 Tworzenie klucza prywatnego i certyfikatu...3 Import kluczy z przeglądarki...9 2 Wstęp PGP - to program
Bardziej szczegółowoPRZEWODNIK PO FEDEX DELIVERY MANAGER DOMESTIC
PRZEWODNIK PO FEDEX DELIVERY MANAGER DOMESTIC 1. Definicje 1.1. FedEx FedEx Express Polska Sp. z o.o. Adres rejestrowy: ul. Krucza 16/22, 00-526 Warszawa, wpisana do rejestru przedsiębiorców Krajowego
Bardziej szczegółowoInternetowy serwis Era mail Aplikacja sieci Web
Internetowy serwis Era mail Aplikacja sieci Web (www.login.eramail.pl) INSTRUKCJA OBSŁUGI Spis treści Internetowy serwis Era mail dostępny przez komputer z podłączeniem do Internetu (aplikacja sieci Web)
Bardziej szczegółowo1. Wstęp 2. Adres usługi 3. Konfiguracja 4. Metody 5. Typy danych 6. Przykład wywołania metody przy użyciu php i biblioteki nusoap 7.
1. Wstęp 2. Adres usługi 3. Konfiguracja 4. Metody 5. Typy danych 6. Przykład wywołania metody przy użyciu php i biblioteki nusoap 7. Odpowiedź serwera Wstęp Usługa udostępniona dla klientów serwisu pakka.pl,
Bardziej szczegółowoInstrukcja integratora - obsługa dużych plików w epuap2
Instrukcja integratora - obsługa dużych plików w epuap2 Wersja: 1.1 Strona 1 z 18 Spis treści SPIS TREŚCI... 2 WPROWADZENIE ORAZ INFORMACJE OGÓLNE... 3 1.1 WSTĘP... 3 1.2 WARUNKI KONIECZNE DO SPEŁNIENIA
Bardziej szczegółowoDESlock+ szybki start
DESlock+ szybki start Wersja centralnie zarządzana Wersja bez centralnej administracji standalone WAŻNE! Pamiętaj, że jeśli chcesz korzystać z centralnego zarządzania koniecznie zacznij od instalacji serwera
Bardziej szczegółowoDokumentacja API BizIn
Dokumentacja API BizIn Spis treści Wstęp... 1 Dostęp do API BizIn... 1 Identyfikatory API... 1 Dostępne akcje... 3 Przykład wywołania API w języku PHP... 3 Pobieranie danych... 3 Wystawianie dokumentu
Bardziej szczegółowoDokumentacja. Wersja: 1.5 Ostatnio zmodyfikowano: Strona 1
Dokumentacja Interfejs komunikacyjny opartego o technologię RESTful Web Services dla systemu ITS we Wrocławiu pozwalającego na zasilanie Repozytorium Danych ITS informacjami pochodzącymi z pojazdów Transportu
Bardziej szczegółowoAplikacje internetowe - laboratorium
Aplikacje internetowe - laboratorium PHP Celem ćwiczenia jest przygotowanie prostej aplikacji internetowej opartej o język PHP. Aplikacja ilustruje takie mechanizmy jak: obsługa formularzy oraz obsługa
Bardziej szczegółowoDOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS. Autor smeskom@smeskom.pl Data 2007-11-04 Wersja 1.
DOKUMENTACJA PROTOKOŁU SMESX Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Autor smeskom@smeskom.pl Data 2007-11-04 Wersja 1.0 Spis treści Dokumentacja protokoł u SmesX...2 1 Zawarto ść
Bardziej szczegółowoSystemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science
Systemy internetowe Wykład 5 Architektura WWW Architektura WWW Serwer to program, który: Obsługuje repozytorium dokumentów Udostępnia dokumenty klientom Komunikacja: protokół HTTP Warstwa klienta HTTP
Bardziej szczegółowoInstrukcja pobrania i instalacji. certyfikatu Microsoft Code Signing. wersja 1.4
Instrukcja pobrania i instalacji certyfikatu Microsoft Code Signing wersja 1.4 Spis treści 1. WSTĘP... 4 2. TWORZENIE CERTYFIKATU... 4 3. WERYFIKACJA... 9 3.1. WERYFIKACJA DOKUMENTÓW... 9 3.1.1. W przypadku
Bardziej szczegółowoSYSTEM ZARZĄDZANIA DANYMI OSOBOWYMI - INSTRUKCJA UŻYTKOWNIKA
SYSTEM ZARZĄDZANIA DANYMI OSOBOWYMI - INSTRUKCJA UŻYTKOWNIKA 1. Wstęp System Zarządzania Danymi Osobowymi (dalej SZDO) składa się z: konsoli użytkownika posiadającej funkcjonalności niezbędne m. in. do
Bardziej szczegółowoSpecyfikacja 1.2.1. Płatności CashBill. Instrukcja podłączenia płatności elektronicznych do typowych zastosowań.
Specyfikacja 1.2.1 Płatności CashBill Instrukcja podłączenia płatności elektronicznych do typowych zastosowań. CashBill Spółka Akcyjna ul. Rejtana 20, 41-300 Dąbrowa Górnicza Tel.: +48 032 764-18-42 Fax:
Bardziej szczegółowoKielce, dnia 27.02.2012 roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / 39 25-344 Kielce
Kielce, dnia 27.02.2012 roku HB Technology Hubert Szczukiewicz ul. Kujawska 26 / 39 25-344 Kielce Tytuł Projektu: Wdrożenie innowacyjnego systemu dystrybucji usług cyfrowych, poszerzenie kanałów sprzedaży
Bardziej szczegółowoManual konfiguracji konta dla fax2mail
Manual konfiguracji konta dla fax2mail Spis treści 1 AKTYWACJA KONTA FAX2MAIL... 3 2 KONFIGURACJA KONTA FAX2MAIL MS OUTLOOK 2003... 5 3 KONFIGURACJA KONTA FAX2MAIL MS OUTLOOK 2010... 11 4 KONFIGURACJA
Bardziej szczegółowoElektroniczna Skrzynka Podawcza
Elektroniczna Skrzynka Podawcza Instrukcja dla administratora Wersja 1.6.0 Przewodnik przeznaczony jest dla użytkowników, którzy administrują kontem urzędu w systemie Elektronicznej Skrzynki Podawczej.
Bardziej szczegółowoCurrenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3
Currenda EPO Instrukcja Konfiguracji Wersja dokumentu: 1.3 Currenda EPO Instrukcja Konfiguracji - wersja dokumentu 1.3-19.08.2014 Spis treści 1 Wstęp... 4 1.1 Cel dokumentu... 4 1.2 Powiązane dokumenty...
Bardziej szczegółowo3S TeleCloud - Aplikacje Instrukcja użytkowania usługi 3S FAX SYSTEM
\ 3S TeleCloud - Aplikacje Instrukcja użytkowania usługi 3S FAX SYSTEM SPIS TREŚCI 1. LOGOWANIE DO APLIKACJI... 3 2. WYGLĄD OKNA... 4 3. SKRZYNKA ODBIORCZA... 5 3.1. SKRZYNKA ODBIORCZA - Objaśnienie kolumn:...
Bardziej szczegółowoTworzenie witryn internetowych PHP/Java. (mgr inż. Marek Downar)
Tworzenie witryn internetowych PHP/Java (mgr inż. Marek Downar) Rodzaje zawartości Zawartość statyczna Treść statyczna (np. nagłówek, stopka) Layout, pliki multimedialne, obrazki, elementy typograficzne,
Bardziej szczegółowoWykaz zmian w programie SysLoger
Wykaz zmian w programie SysLoger Pierwsza wersja programu 1.0.0.1 powstała we wrześniu 2011. Funkcjonalność pierwszej wersji programu: 1. Zapis logów do pliku tekstowego, 2. Powiadamianie e-mail tylko
Bardziej szczegółowoMODEM GSM-01. INSTRUKCJA OBŁUGI MODUŁU KOMUNIKACYJNEGO GSM-01 wersja 1.0 GSM-01 INSTRUKCJA OBSŁUGI - 1 -
INSTRUKCJA OBŁUGI MODUŁU KOMUNIKACYJNEGO GSM-01 wersja 1.0 GSM-01 INSTRUKCJA OBSŁUGI - 1 - - 2 - Spis treści 1. Wymagania...5 2. Komendy SMS...5 3. Konfiguracja przez SMS...6 4. Łączenie modułu GSM aplikacją
Bardziej szczegółowo