Specyfikacja API bramki SMS/MMS/IVR

Save this PDF as:
 WORD  PNG  TXT  JPG

Wielkość: px
Rozpocząć pokaz od strony:

Download "Specyfikacja API bramki SMS/MMS/IVR"

Transkrypt

1 Specyfikacja API bramki SMS/MMS/IVR wersja 1.4 Piotr Isajew 13 kwietnia 2011 c 2011 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 Zabezpieczenie komunikacji 17 1

3 6 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 Historia zmian Zmiany w wersji

4 1. Wprowadzenie API działa w oparciu o proste komunikaty XML przekazywane za pomocą metody HTTP POST. 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 wymaga określenia dla klienta następujących parametrów: adres URL bramki, na który będą przesyłane żądania, 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). Dodatkowo skonfigurowanie dostępu będzie wymagało określenia parametrów, o których mowa w części 5. 3

5 1.2 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 przeznaczony 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. Zabezpieczenie komunikacji 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. 17

19 6. 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ę. 6.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. 18

20 6.2 Wysyłanie wiadomości SMS za pomoca PHP W najprostszym przypadku wysyłanie wiadomości SMS ze skryptów PHP może odbywać się z wykorzystaniem funkcji jak np.: function sendsms($msgid, $destnumber, $text) { $h = curl_init(); $request = <?xml version="1.0" encoding="utf-8"?> <gateway-request. type="sms-send-request"> <request-auth><partnerlogin>przypominamy_test. </partnerlogin><partnerpassword>naniby</partnerpassword></request-auth>. <request-data><sms-send-request><message-id>. $msgid. </message-id>. <msisdn>. $destnumber. </msisdn><sms-text>. $text. </sms-text><confirmation-request/></sms-send-request></request-data>. </gateway-request> ; } curl_setopt($h, CURLOPT_URL, ); curl_setopt($h, CURLOPT_RETURNTRANSFER, true); curl_setopt($h, CURLOPT_POST, true); curl_setopt($h, CURLOPT_POSTFIELDS, $request); $rv = curl_exec($h); curl_close($h); return $rv; Wówczas wywołanie funkcji $res = sendsms(5, , Przykladowy sms ); Spowoduje podobnie jak w przykładzie 6.1 przekazanie do systemu żądania wysłania pojedynczego SMS a. Treść odpowiedzi serwera będzie w tym przypadku zwrócona przez funkcję i dostępna w zmiennej $res. 6.3 Odbiór wiadomości przychodzacych za pomoca PHP Przykładowy skrypt PHP obsługujący żądania POST kierowane na adres URL przyjmujący po stronie klienta powiadomienia z systemu mógłby mieć postać: <?php function parseinput($input) { $doc = new DomDocument(); $doc->loadxml($input); $root = $doc->firstchild; if($root->nodename == gateway-response && $root->attributes->getnameditem( type )->value == incoming-sms-message ) { for($item = $root->firstchild; $item!= NULL; $item = $item->nextsibling) { if($item->nodename == incoming-sms-message ) { $msgdata = array(); 19

21 for($fld = $item->firstchild; $fld!= NULL; $fld = $fld->nextsibling) { $msgdata[$fld->nodename] = $fld->nodevalue; } } } // Tu sensowna obsługa odebranych wiadomości echo "Odebrano wiadomość #". $msgdata[ message-id ]. " z numeru ". $msgdata[ msisdn ]. " o treści: ". $msgdata[ sms-text ]. "<br/>\n"; } } $in = file_get_contents( php://input ); parseinput($in);?> 20

22 7. Historia zmian 7.1 Zmiany w wersji Ulepszenie diagnostyki błędów (rozdział 4) 2. Wprowadzenie obsługi wiadomości głosowych (rozdział 3) 3. Zmiana typu komunikatu dla wiadomości przychodzących (punkt 2.4.1) 21

Specyfikacja API bramki SMS/MMS/TTS

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ółowo

Specyfikacja API bramki SMS/MMS/IVR

Specyfikacja API bramki SMS/MMS/IVR Specyfikacja API bramki SMS/MMS/IVR wersja 1.5 Piotr Isajew (pki@ex.com.pl) 14 września 2011 c 2010-2011 EXPERTUS, http://www.ex.com.pl Spis treści 1 Wprowadzenie 3 1.1 Parametry konfiguracyjne................................

Bardziej szczegółowo

Dokumentacja 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 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ółowo

DOKUMENTACJA TECHNICZNA SMS API MT

DOKUMENTACJA 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ółowo

Dokumentacja smsapi wersja 1.4

Dokumentacja 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ółowo

Specyfikacja instalacji usługi SMS Premium w Przelewy24.pl

Specyfikacja 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ółowo

Gatesms.eu Mobilne Rozwiązania dla biznesu

Gatesms.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ółowo

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Specyfikacja 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ółowo

Specyfikacja techniczna. mprofi Interfejs API

Specyfikacja 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ółowo

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.

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. 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ółowo

API transakcyjne BitMarket.pl

API 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ółowo

Dokumentacja techniczna API systemu SimPay.pl

Dokumentacja 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ółowo

Funkcje dodatkowe. Wersja 1.2.1

Funkcje 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ółowo

Dokumentacja API BizIn

Dokumentacja 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ółowo

DOKUMENTACJA TECHNICZNA KurJerzyAPI wersja 1.0

DOKUMENTACJA 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ółowo

BRAMKA HTTP SMS XML Dokumentacja techniczna. wersja 3.32

BRAMKA 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ółowo

Funkcje dodatkowe. Wersja 1.2.1

Funkcje 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ółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady 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ółowo

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Zasady 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ółowo

Dokumentacja interfejsu Webservices API. Wersja 2.0 [12 stycznia 2014] http://bramka.gsmservice.pl e-mail: bramka@gsmservice.pl

Dokumentacja 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ółowo

System DiLO. Opis interfejsu dostępowego v. 2.0

System 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ółowo

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

Zasady 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ółowo

DOKUMENTACJA 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. 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ółowo

Procedura Walidacyjna Interfejs

Procedura 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ółowo

Dokumentacja techniczna SMS MO

Dokumentacja 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ółowo

MINISTERSTWO 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 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ółowo

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

Spis 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ółowo

Dokumentacja API BizIn

Dokumentacja 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ółowo

DOKUMENTACJA 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 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ółowo

SMS Kod Automatyczny

SMS 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ółowo

ZPKSoft 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 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ółowo

OPIS TECHNICZNY SYSTEM HOSTED SMS

OPIS 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ółowo

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

Zasady 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ółowo

Dokumentacja 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 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ółowo

Dokumentacja REST API v 3.0

Dokumentacja 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ółowo

Wdroż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 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ółowo

INSTRUKCJA OBSŁUGI PANELU ADMINISTRACYJNEGO MÓJ DOTPAY v0.1

INSTRUKCJA 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ółowo

Dokumentacja 2SMS

Dokumentacja  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ółowo

Dokumentacja 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 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ółowo

Wdroż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 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ółowo

DOKUMENTACJA 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 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ółowo

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

Automater.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ółowo

Dotacje na innowacje - Inwestujemy w Waszą przyszłość ZAPYTANIE OFERTOWE

Dotacje 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ółowo

Instrukcja konfiguracji funkcji skanowania

Instrukcja 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ółowo

Instrukcja korzystania z usługi EMAIL2SMS. Wersja 2.0 [12 stycznia 2014] http://bramka.gsmservice.pl e-mail: bramka@gsmservice.pl

Instrukcja 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ółowo

Dokumentacja techniczna SMS MO

Dokumentacja 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ółowo

Wdroż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 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ółowo

Przykładowa integracja systemu Transferuj.pl

Przykł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ółowo

ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI

ZABEZPIECZENIE 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ółowo

PHP: bloki kodu, tablice, obiekty i formularze

PHP: 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ółowo

Tworzenie witryn internetowych PHP/Java. (mgr inż. Marek Downar)

Tworzenie 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ółowo

Dokumentacja interfejsu API

Dokumentacja 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ółowo

Połączenie Partnera z serwisem JustPay poprzez - METODĘ 2

Połą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ółowo

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

Specyfikacja 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ółowo

Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do

Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do Sesje i ciasteczka Kontrola sesji w PHP HTTP jest protokołem bezstanowym (ang. stateless) nie utrzymuje stanu między dwoma transakcjami. Kontrola sesji służy do śledzenia użytkownika podczas jednej sesji

Bardziej szczegółowo

Warszawa Specyfikacja techniczna. mprofi Interfejs API wersja 1.0.7

Warszawa 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ółowo

Dokumentacja REST API v 3.0

Dokumentacja 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ółowo

DOKUMENTACJA IMPLEMENTACJI MECHANIZMÓW OBSŁUGI AHMES SMS (soap) 2013-03-24

DOKUMENTACJA 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ółowo

Propozycja standaryzacji usługi lokalizacji adresu

Propozycja standaryzacji usługi lokalizacji adresu dr inż. Waldemar Izdebski 1,2 mgr inż. Andrzej Bielasty 2 Propozycja standaryzacji usługi lokalizacji adresu Numery adresowe są jednym z najprostszych elementów danych przestrzennych. Niemniej jednak są

Bardziej szczegółowo

DOKUMENTACJA INTERFEJSU API - HTTPS

DOKUMENTACJA INTERFEJSU API - HTTPS DOKUMENTACJA INTERFEJSU API - HTTPS WERSJA 0.1 DATA PUBLIKACJI : 01.03.2014 SPIS TREŚCI Spis treści Wprowadzenie 1 Dostęp do usługi notowania online 2 Opis struktur danych 3 Kody błędów 5 Historia wersji

Bardziej szczegółowo

Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013

Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013 Aktualizacja SMSFall v. 1.1.5 Data publikacji: 20-05-2013 Wersja Standard i Plus: we właściwościach terminala dodano wskaźnik poziomu sygnału urządzenia GSM wyrażony w dbm. Podstawa teoretyczna: http://pl.wikipedia.org/wiki/dbm.

Bardziej szczegółowo

TELETRONIKA. Aplikacje sieciowe CALLNET - instrukcja modułu SMS (11.2) www.teletronika.pl

TELETRONIKA. Aplikacje sieciowe CALLNET - instrukcja modułu SMS (11.2) www.teletronika.pl TELETRONIKA www.teletronika.pl Aplikacje sieciowe CALLNET - instrukcja modułu SMS (11.2) W ramach oddzielnej licencji, oferowany jest moduł oprogramowania dla aplikacji 'Callnet-serwer' umożliwiający wysyłanie

Bardziej szczegółowo

Wdroż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 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ółowo

Implementacja mechanizmu SkyCashClick Wersja 0.1

Implementacja 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ółowo

Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel"

Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny doręczyciel Opis przykładowego programu realizującego komunikację z systemem epuap wykorzystując interfejs komunikacyjny "doręczyciel" dn.24.09.2009 r. Dokument opisuje przykładowy program doręczający dokumenty na

Bardziej szczegółowo

Proces rozliczania recept realizowanych od 01.01.2012

Proces rozliczania recept realizowanych od 01.01.2012 Proces rozliczania recept realizowanych od 01.01.2012 Materiały dla Aptek i Punktów aptecznych Portal SZOI KAMSOFT S.A. Podstawy legislacyjne procesu refundacji recept Obsługa nowego sposobu rozliczania

Bardziej szczegółowo

Gatesms.eu Mobilne Rozwiązania dla biznesu

Gatesms.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ółowo

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Załącznik Nr 1 Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Wersja 1.0 Na podstawie: Europejskiej Modelowej Umowy o EDI (w skrócie:

Bardziej szczegółowo

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.

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. 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ółowo

Instrukcja podłączenia transakcji Premium SMS przez Sprzedawcę

Instrukcja podłączenia transakcji Premium SMS przez Sprzedawcę Instrukcja podłączenia transakcji Premium SMS przez Sprzedawcę Podłączenie transakcji Premium SMS w witrynie internetowej Sprzedawcy przebiega następująco : 1. Należy zalogować się do panelu klienta w

Bardziej szczegółowo

Przykładowa integracja systemu tpay.com KIP S.A. ul. Św. Marcin 73/ Poznań.

Przykł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ółowo

Laboratorium 3.4.2: Zarządzanie serwerem WWW

Laboratorium 3.4.2: Zarządzanie serwerem WWW Laboratorium 3.4.2: Zarządzanie serwerem WWW Topologia sieci Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Domyślna brama R1-ISP S0/0/0 10.10.10.6 255.255.255.252 Nie dotyczy Fa0/0 192.168.254.253

Bardziej szczegółowo

Wdroż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 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ółowo

Laboratorium 6.7.2: Śledzenie pakietów ICMP

Laboratorium 6.7.2: Śledzenie pakietów ICMP Topologia sieci Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Domyślna brama R1-ISP R2-Central Serwer Eagle S0/0/0 10.10.10.6 255.255.255.252 Nie dotyczy Fa0/0 192.168.254.253 255.255.255.0

Bardziej szczegółowo

Języki programowania wysokiego poziomu. PHP cz.3. Formularze

Języki programowania wysokiego poziomu. PHP cz.3. Formularze Języki programowania wysokiego poziomu PHP cz.3. Formularze Formularze Sposób przesyłania danych formularza do serwera zależy od wybranej metody HTTP: Metoda GET

Bardziej szczegółowo

Asynchroniczne interfejsy

Asynchroniczne interfejsy Asynchroniczne interfejsy AJAX WWW mgr inż. Rafał Grycuk mgr inż. Patryk Najgebauer Strona służbowa: http://iisi.pcz.pl/~rgrycuk/ Kontakt: rafal.grycuk@iisi.pcz.pl Konsultacje: Środa, godz. 12-14 Agenda

Bardziej szczegółowo

Wysyłanie pliku na serwer. Plik na serwerze.

Wysyłanie pliku na serwer. Plik na serwerze. Wysyłanie pliku na serwer Dzięki PHP możemy w łatwy i przyjemny sposób obsłużyć pliki uploadowane na serwer. Jednak, by prawidłowo wysłać plik, niezbędny będzie odpowiedni formularz HTML. Poniżej przedstawię

Bardziej szczegółowo

System IVR. Opis elementów systemu

System IVR. Opis elementów systemu System IVR Opis elementów systemu 1. Wstęp Na system IVR (IVR Pack) składają się następujące usługi: IVR Player, IVR Menu, IVR List, IVR Switch. Cennik usług IVR dostępny jest na stronie www.ipfon.pl.

Bardziej szczegółowo

Wdrożenie modułu płatności eservice dla systemu PrestaShop

Wdrożenie modułu płatności eservice dla systemu PrestaShop Wdrożenie modułu płatności eservice dla systemu PrestaShop Wersja 04 Wrzesień 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ółowo

API 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/ 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ółowo

Atrybuty SMS. Nazwa Twojej firmy lub produktu w SMS-ie podniesie prestiż Twojej wiadomości

Atrybuty SMS. Nazwa Twojej firmy lub produktu w SMS-ie podniesie prestiż Twojej wiadomości Atrybuty SMS Wiadomości tekstowe SMS wbrew pozorom posiadają wiele atrybutów, które można wykorzystać na wiele sposobów. W tym dziale opisaliśmy atrybuty i najważniejsze kwestie związane z posługiwaniem

Bardziej szczegółowo

JEDEN NUMER - CAŁA FIRMA POD JEDNYM NUMEREM

JEDEN NUMER - CAŁA FIRMA POD JEDNYM NUMEREM JEDEN NUMER JEDEN NUMER - CAŁA FIRMA POD JEDNYM NUMEREM GŁOS (VPABX) SMS/MMS JEDEN NUMER - stacjonarny lub komórkowy numer pod którym dostępni są wszyscy pracownicy firmy Możliwość przeniesienia numeru

Bardziej szczegółowo

Instrukcja pobrania i instalacji. certyfikatu Microsoft Code Signing. wersja 1.4

Instrukcja 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ółowo

Instrukcja integratora - obsługa dużych plików w epuap2

Instrukcja 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ółowo

1.2 Prawa dostępu - Role

1.2 Prawa dostępu - Role Portlet Użytkownik Login Uprawnienie Rola Kontekst podmiotu Okno w serwisie portalu, udostępniające konkretne usługi lub informacje, na przykład kalendarz lub wiadomości Jest to osoba korzystająca z funkcjonalności

Bardziej szczegółowo

Kielce, 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 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ółowo

SMS Kod Automatyczny

SMS Kod Automatyczny Dokumentacja 1.0.0 SMS Kod Automatyczny Dokumentacja dla SMS Kod Automatyczny 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 Infolinia: 0

Bardziej szczegółowo

Modele danych walidacja widoki zorientowane na model

Modele danych walidacja widoki zorientowane na model Modele danych walidacja widoki zorientowane na model 1. Wprowadzenie Modele danych Modele danych w ASP.NET MVC to klasy znajdujące się w katalogu Models. Ich zadaniem jest mapowanie danych przesyłanych

Bardziej szczegółowo

Dokumentacja API. SOAP - webservice v. 0.2.1

Dokumentacja API. SOAP - webservice v. 0.2.1 Dokumentacja API SOAP - webservice v. 0.2.1 Zawsze wymagane parametry WSDL https://api.fabrykasms.pl/0.2/soap?wsdl http://fabrykasms.pl/api/acc/ przy koncie api wybieramy zdalne używanie aby uzyskać wszystkie

Bardziej szczegółowo

Ministerstwo Finansów

Ministerstwo Finansów Ministerstwo Finansów System e-deklaracje Instrukcja użytkownika Wersja 1.00 1/21 SPIS TREŚCI I. INFORMACJE OGÓLNE...3 WYMAGANIA NIEZBĘDNE DO SKŁADANIA DEKLARACJI ZA POMOCĄ INTERAKTYWNYCH FORMULARZY...3

Bardziej szczegółowo

Dokumentacja Użytkownika Systemu

Dokumentacja Użytkownika Systemu Dokumentacja Użytkownika Systemu Porównywarki cen Liquid Wersja 2016.2 Spis treści 1 WSTĘP... 3 2 OPIS OBSZARU... 4 2.1 TOWARY... 5 2.2 RELACJE... 5 2.3 EDYTUJ... 6 2.3.1 KONFIGURACJA... 6 2.3.2 KATEGORIE...

Bardziej szczegółowo

Specyfikacja 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ń. 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ółowo

Remote Quotation Protocol - opis

Remote 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ółowo

Currenda EPO Instrukcja Konfiguracji. Wersja dokumentu: 1.3

Currenda 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ółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to przeznaczone jest dla właścicieli sklepów internetowych opartych

Bardziej szczegółowo

API 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/ 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ółowo

Baza numerów Wersja 1.1

Baza 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ółowo

Rys. 1. Wynik działania programu ping: n = 5, adres cyfrowy. Rys. 1a. Wynik działania programu ping: l = 64 Bajty, adres mnemoniczny

Rys. 1. Wynik działania programu ping: n = 5, adres cyfrowy. Rys. 1a. Wynik działania programu ping: l = 64 Bajty, adres mnemoniczny 41 Rodzaje testów i pomiarów aktywnych ZAGADNIENIA - Jak przeprowadzać pomiary aktywne w sieci? - Jak zmierzyć jakość usług sieciowych? - Kto ustanawia standardy dotyczące jakości usług sieciowych? - Jakie

Bardziej szczegółowo

Załącznik nr 1 do Instrukcji użytkownika minisiis, SIIS 5.x. Spis kodów błędów

Załącznik nr 1 do Instrukcji użytkownika minisiis, SIIS 5.x. Spis kodów błędów Załącznik nr 1 do Instrukcji użytkownika minisiis, SIIS 5.x Spis kodów błędów Stan na 9-02-2015 Numer GRUPA 100 Błędy ogólnego przetwarzania plików 101 Brak pliku do przetworzenia! 102 Wystąpiła awaria

Bardziej szczegółowo

PANEL ADMINISTRACYJNY SPRZEDAWCY SZYBKI START

PANEL ADMINISTRACYJNY SPRZEDAWCY SZYBKI START Biuro Obsługi Klienta Dotpay ul. Wielicka 72, 30-552 Kraków tel. +48 12 688 26 00 e-mail: bok@dotpay.pl PANEL ADMINISTRACYJNY SPRZEDAWCY SZYBKI START Wersja 1.29.6.1 SPIS TREŚCI Strona 2 / 15 WSTĘP...

Bardziej szczegółowo