Specyfikacja API bramki SMS/MMS/IVR

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

Download "Specyfikacja API bramki SMS/MMS/IVR"

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Płatności CashBill - SOAP

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

PGP - Pretty Good Privacy. Użycie certyfikatów niekwalifikowanych w programie PGP

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

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

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

Elektroniczna Skrzynka Podawcza

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

Bezpieczne Zakupy. - specyfikacja techniczna implementacji uproszczonej

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

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

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

Aplikacje internetowe - laboratorium

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

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

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

SYSTEM INFORMATYCZNY KS-SEW

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

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

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

Internetowy serwis Era mail Aplikacja sieci Web

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

Manual konfiguracji konta dla fax2mail

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

DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.0

DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.0 DOKUMENTACJA PROTOKOŁU SMESX Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.0 Autor smeskom@smeskom.pl Data 2008-08-21 Wersja 2.0 (rev. 1) Spis treści Dokumentacja protokołu

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

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

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

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

Technologie sieciowe Sprawozdanie z labolatorium. Lista 5

Technologie sieciowe Sprawozdanie z labolatorium. Lista 5 Politechnika Wrocławska Wydział Podstawowych Problemów Techniki Technologie sieciowe Sprawozdanie z labolatorium Lista 5 Autor: Piotr Kosytorz IIrokInf. indeks: 166174 Prowadzący: dr inż. Łukasz Krzywiecki

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

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

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

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

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

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

Wykaz zmian w programie SysLoger

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

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

System automatycznego wysyłania SMSów SaldoSMS

System automatycznego wysyłania SMSów SaldoSMS KWSOFT Pleszew 8-03-2005 Ul. Witkiewicza 9 63-300 Pleszew tel. 0509 370 429 http://www.kwsoft.com.pl kwsoft@kwsoft.com.pl System automatycznego wysyłania SMSów SaldoSMS Przygotowali: Krzysztof Juśkiewicz

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

Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24

Dokumentacja Użytkownika Systemu. Integracja z Okazje.info, Skąpiec, Sklepy24 Dokumentacja Użytkownika Systemu Integracja z Okazje.info, Skąpiec, Sklepy24 Wersja 2016 Spis treści 1 INTEGRACJA... 3 2 REJESTRACJA... 4 2.1 OKAZJE.INFO... 4 2.2 SKĄPIEC... 4 2.3 SKLEPY24.PL... 4 3 KONFIGURACJA...

Bardziej szczegółowo

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

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center Spis treści Konfiguracja Microsoft Outlook 2007... 3 Konfiguracja dla POP3... 7 Konfiguracja dla IMAP... 11 Sprawdzenie poprawnoś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

Aplikacje WWW - laboratorium

Aplikacje WWW - laboratorium Aplikacje WWW - laboratorium PHP. Celem ćwiczenia jest przygotowanie prostej aplikacji internetowej wykorzystującej technologię PHP. Aplikacja pokazuje takie aspekty, obsługa formularzy oraz zmiennych

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

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

PODRĘCZNIK OBSŁUGI BUSINESSNET

PODRĘCZNIK OBSŁUGI BUSINESSNET PODRĘCZNIK OBSŁUGI BUSINESSNET. LOGOWANIE. AUTORYZACJA ZLECENIA. NOWY KLUCZ. PRZELEWY 5. ZLECENIA STAŁE 6. MODUŁ PRAWNY 7. DOSTĘP DO DEALINGNET 8. ANKIETA MIFID 9. CERTYFIKAT KWALIFIKOWANY JAK ZALOGOWAĆ

Bardziej szczegółowo

PODRĘCZNIK OBSŁUGI BUSINESSNET

PODRĘCZNIK OBSŁUGI BUSINESSNET PODRĘCZNIK OBSŁUGI BUSINESSNET. LOGOWANIE. AUTORYZACJA ZLECENIA. NOWY KLUCZ. PRZELEWY 5. ZLECENIA STAŁE 6. MODUŁ PRAWNY 7. DOSTĘP DO DEALINGNET 8. CERTYFIKAT KWALIFIKOWANY JAK ZALOGOWAĆ SIĘ DO BUSINESSNET

Bardziej szczegółowo

DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.2

DOKUMENTACJA PROTOKOŁU SMESX. Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.2 DOKUMENTACJA PROTOKOŁU SMESX Platforma SMeSKom - instrukcja korzystania z interfejsu HTTPS Protokół w wersji 2.2 Autor smeskom@smeskom.pl Data 16.06.2009 Wersja 2.2 (rev. 1) Spis treści Dokumentacja protokołu

Bardziej szczegółowo

Ogólnopolskie Repozytorium Prac Dyplomowych

Ogólnopolskie Repozytorium Prac Dyplomowych Ogólnopolskie Repozytorium Prac Dyplomowych System Informacji o Szkolnictwie Wyższym POL-on Źródła danych i sposób zasilania, formaty i aspekty organizacyjne Strona 1 z 8 Spis treści Spis treści 1.Źródła

Bardziej szczegółowo

PROTOKOŁY OBSŁUGI POCZTY ELEKTRONICZNEJ

PROTOKOŁY OBSŁUGI POCZTY ELEKTRONICZNEJ PROTOKOŁY OBSŁUGI POCZTY ELEKTRONICZNEJ Poczta elektroniczna służy do przesyłania komunikatów tekstowych, jak również dołączonych do nich informacji nietekstowych (obraz, dźwięk) pomiędzy użytkownikami

Bardziej szczegółowo

INFORMACJE NA TEMAT STRUKTURY PLIKU XML

INFORMACJE NA TEMAT STRUKTURY PLIKU XML INFORMACJE NA TEMAT STRUKTURY PLIKU XML Sierpień 2015 str. 1 1. Wstęp Przygotowanie pliku o określonej strukturze jest kluczem do sprawnej integracji Państwa ofert z serwisem Ceneo. Przygotowany plik należy

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

Instrukcja obsługi programu Klient SMS v.1.0

Instrukcja obsługi programu Klient SMS v.1.0 Instrukcja obsługi programu Klient SMS v.1.0 Rozpoczęcie pracy z programem Aby rozpocząć pracę z aplikacją kliencką należy uruchomić dowolną przeglądarkę internetową i wpisać adres: lub http://

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

Dokumentacja Użytkownika Systemu

Dokumentacja Użytkownika Systemu Dokumentacja Użytkownika Systemu Integracja z Okazje.info, Skąpiec, Sklepy24 Wersja 7.9 Spis treści 1 INTEGRACJA... 3 2 REJESTRACJA... 4 2.1 OKAZJE.INFO... 4 2.2 SKĄPIEC... 4 2.3 SKLEPY24.PL... 4 3 KONFIGURACJA...

Bardziej szczegółowo

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail

1 Moduł E-mail. 1.1 Konfigurowanie Modułu E-mail 1 Moduł E-mail Moduł E-mail daje użytkownikowi Systemu możliwość wysyłania wiadomości e-mail poprzez istniejące konto SMTP. System Vision może używać go do wysyłania informacji o zdefiniowanych w jednostce

Bardziej szczegółowo

IIIIIIIIIIIIIIIMMIMMIII

IIIIIIIIIIIIIIIMMIMMIII IIIIIIIIIIIIIIIMMIMMIII O programie Program Itelix itender Manager przeznaczony jest do zarządzania zapytaniami ofertowymi przesyłanymi za pomocą poczty elektronicznej przez firmy korzystające z systemu

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

Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, e-mail. A. Kisiel,Protokoły DNS, SSH, HTTP, e-mail

Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, e-mail. A. Kisiel,Protokoły DNS, SSH, HTTP, e-mail N, Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, e-mail 1 Domain Name Service Usługa Domain Name Service (DNS) Protokół UDP (port 53), klient-serwer Sformalizowana w postaci protokołu DNS Odpowiada

Bardziej szczegółowo

OFERTA NA CENTRALĘ WIRTUALNĄ DLA USŁUGI INFOLINII 800 / 801

OFERTA NA CENTRALĘ WIRTUALNĄ DLA USŁUGI INFOLINII 800 / 801 JNS Sp. z o.o. ul. Wróblewskiego 18 93-578 Łódź NIP: 725-189-13-94 tel. +48 42 209 27 01, fax. +48 42 209 27 02 e-mail: biuro@jns.pl Oferta obowiązuje od 1.09.2013 r. OFERTA NA CENTRALĘ WIRTUALNĄ DLA USŁUGI

Bardziej szczegółowo