API de Dados Abertos com dados processados pelo grupo de monitoramento de Queimadas do INPE.

Description of Instagram RESTful API. Current limitations: * Instagram service does not support [cross origin headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) for security reasons, therefore it is not possible to use Swagger UI and make API calls directly from browser. * Modification API requests (`POST`, `DELETE`) require additional security [scopes](https://instagram.com/developer/authorization/) that are available for Apps [created on or after Nov 17, 2015](http://instagram.com/developer/review/) and started in [Sandbox Mode](http://instagram.com/developer/sandbox/). * Consider the [Instagram limitations](https://instagram.com/developer/limits/) for API calls that depends on App Mode. **Warning:** For Apps [created on or after Nov 17, 2015](http://instagram.com/developer/changelog/) API responses containing media objects no longer return the `data` field in `comments` and `likes` nodes. Last update: 2015-11-28

This is the documentation for PIM Micro services. In order to use this tool you need to have Basic Auth credentials and a client id. If you dont have one, please make sure to request one by sending an email to the PIM MS team: [pim.360.team@intel.com](mailto:pim.360.team@intel.com?subject=PIMServices)

Interactive Brokers Web API for 3rd Party Companies

IP2Location web service providing a service to do a reverse lookup of an IP address to an ISO3166 country code, region or state, city, latitude and longitude, ZIP/Postal code, time zone, Internet Service Provider (ISP) or company name, domain name, net speed, area code, weather station code, weather station name, mobile country code (MCC), mobile network code (MNC) and carrier brand, elevation, usage type, address type and IAB category. There are also 7 categories of additional add-on response fields supported such as metro, olson time zone, translations and more. Refer to https://www.ip2location.com/web-service/ip2location for further information.

IP2Proxy allows instant detection of anonymous proxy, VPN, TOR exit nodes, search engine robots (SES), data center ranges (PX2-PX10), residential proxies (PX10) and VPN provider name (PX11) by IP address. It also returns the threat type of the proxy (PX9 or higher). Visit https://www.ip2location.com/web-service/ip2proxy for further information.

The iQualify API offers management responses for building learning experiences using your iQualify instance data. Once you’ve registered with iQualify, you can request an API access token by navigating to the API access section of the "Account Settings" area. Find out how to [Request your API access token](https://www.iqualify.com/help/connecting-iqualify-to-other-systems/api/how-to-access-and-manage-your-api-token) on our Knowledge base. All endpoints are only accessible via https and are located at api.iqualify.com. For instance: you can find your current offerings by accessing the following URL: https://api.iqualify.com/v1/offerings/current

This API allows to config/change/delete Internet Exchange services. # Filters When querying collections, the provided query parameters are validated. Unknown query parameters are ignored. Providing invalid filter values should yield a validation error.

The Product Library API is used for managing merchant's product information and product images.

# Welcome Implementing a new tool can be daunting, but it doesn't have to. You can implement journy.io in a few different ways to ensure it fits with the rest of your tech stack seamlessly. We welcome your feedback, ideas and suggestions. We really want to make your life easier, so if we’re falling short or should be doing something different, we want to hear about it. Send us an email at [hi@journy.io](mailto:hi@journy.io) or reach out via the chat on our website or on our platform. There are multiple ways you can send us data about users and accounts. We have both frontend and backend APIs, which can be used together at the same time. If you already use [Segment](https://segment.com/), you can [get up and running with journy.io in seconds](https://help.journy.io/en/articles/6488307-the-segment-connector). # Concepts ## Users The most basic entity is a user, a specific individual that completed an interaction with your product. We support multiple types of users, often differentiated by it's external ID prefix. E.g. In the case you are building an ordering app, there could easily be an administrator (who updates products and checks for orders) and the end-customers who place orders. One could have a typical ADM-XXXXXXXX ID, while the other would be referenced by USR-XXXXXXXXX. ## Accounts In B2B SaaS, users can be part of multiple accounts. E.g. Imagine you're building a content scheduling app where an agency can manage the social media posts of their clients. Each client of the agency has its own account in the product. If your app doesn't have the concept of a team or group of users, you can ignore accounts. ## Events An event is a data point that represents an interaction between a user and/or an account; and your product. Events can represents any range of interactions. E.g. Every time a customer creates an invoice in an invoicing app. Actions like creating an invoice can be tracked as an event in journy.io. It's critical to track events properly. You'll need to provide either an account ID, or a user ID, or both; when tracking an event. E.g. If a user updates his personal settings, you can omit the account ID as the event would not be related to any account. In a same logic, an account could get a 'suspend account' event (with account ID) from an internal process, whereas no user would be associated. In most cases, events will be associated to both 1 user and 1 account. You can optionally pass extra details as metadata (e.g. amount of the invoice). This gets particarly powerfull when creating computed properties on those event metadata. E.g. Our above ordering app could send journy.io 'Place Order' events with metadata 'price', on which journy.io very easily would compute a total order value (for each account) for the last 30 days. 💡 Metadata does not update the properties of a user or account. # Frontend vs backend The best implementations we see employ a hybrid approach to maximize data quality while maintaining the flexibility to easily collect the data they need. We recommend using our JavaScript snippet to track screen views and our backend API to sync users, sync accounts and track events. When evaluating how to track a particular event, we suggest starting with server-side and only use frontend if it's not possible to collect purely server-side. This can be the case if you need to track interactions with your product that don't result in any natural server requests (such as a button click that opens a modal). # Frontend ## Setup 💡 You can find the JavaScript snippet in the website settings in the connections view. Copy the JavaScript snippet and place it in the head or body of your application. The snippet automatically calls `journy("init", { ... })` and `journy("pageview")`. ## Identify user 💡 A user ID should be a robust, static, unique identifier that you recognize a user by in your own systems. Because these IDs are consistent across a customer’s lifetime, you should include a user ID in identify calls as often as you can. Ideally, the user ID should be a database ID. 💡 journy.io does not recommend using simple email addresses or usernames as user ID, as these can change over time. journy.io recommends that you use static IDs instead, so the IDs never change. When you use a static ID, you can still recognize the user in your analytics tools, even if the user changes their email address. 💡 The properties `full_name`, `first_name`, `last_name`, `phone` and `registered_at` will be used for creating contacts in destinations like Intercom, HubSpot, Salesforce, ... `journy("identify")` allows you to identify the user that is currently using your product. ```ts journy("identify", { // Email or user ID is required email: "john.doe@acme.com", // Unique identifier for the user in your database userId: "20", // Optional // Hash of the user ID using a backend secret // You can find the secret in the website settings // Recommended to prevent spoofing verification: "hash", // Optional properties: { full_name: "John Doe", // or first_name: "John", last_name: "Doe", phone: "123", registered_at: new Date(/* ... */), is_admin: true, key_with_empty_value: "", this_property_will_be_deleted: null, }, }); ``` ## Identify account 💡 An account ID should be a robust, static, unique identifier that you recognize an account by in your own systems. Ideally, the account ID should be a database ID. 💡 The properties `name`, `mrr`, `plan` and `registered_at` will be used to create companies in destinations like Intercom, HubSpot, Salesforce, ... `journy("account")` allows you to identify the business account (i.e. organization) using your product. ```ts journy("account", { // Required // Unique identifier for the account in your database accountId: "30", // Optional // Hash of the account ID using a backend secret // You can find the secret in the website settings // Recommended to prevent spoofing verification: "hash", // Optional properties: { name: "ACME, Inc", mrr: 399, plan: "Pro", registered_at: new Date(/* ... */), is_paying: true, key_with_empty_value: "", this_property_will_be_deleted: null, }, }); ``` ## Send page view 💡 In applications, we advise you to use screen views instead of page views. The JavaScript snippet in the site settings includes a `pageview` by default. ```ts journy("pageview"); ``` If you have a B2B application, we recommend to set account ID for every page view that happens within the context of an account. 💡 An account ID should be a robust, static, unique identifier that you recognize an account by in your own systems. Ideally, the account ID should be a database ID. ```ts journy("pageview", { accountId: "30", // Optional // Hash of the account ID using a backend secret // You can find the secret in the website settings // Recommended to prevent spoofing verification: "hash", }); ``` ## Send screen view In applications, we strongly advise you to use screen views instead of page views. Page URLs in applications often include the account ID (e.g. https://app.acme.com/accountId/settings). This makes it difficult to create signals, segments, ... based on those URLs. That's what screen views solve. It allows you to set a name for the screen being viewed (e.g. Account settings). ```ts journy("screen", { name: "Personal settings" }); ``` If you have a B2B application, we recommend to set account ID for every screen view that happens within the context of an account. Example: "Personal settings" would be without account ID, "Team settings" would be with account ID. 💡 An account ID should be a robust, static, unique identifier that you recognize an account by in your own systems. Ideally, the account ID should be a database ID. ```ts journy("screen", { name: "Account settings", accountId: "30", // Optional // Hash of the account ID using a backend secret // You can find the secret in the website settings // Recommended to prevent spoofing verification: "hash", }); ``` ## Trigger an event 💡 Use past tense for event names. User events: ```js journy("event", { // required name: "signed_in", // optional metadata: { key: "value", }, }); ``` Account events: 💡 An account ID should be a robust, static, unique identifier that you recognize an account by in your own systems. Ideally, the account ID should be a database ID. ```js journy("event", { // required name: "created_invoice", accountId: "30", // Optional // Hash of the account ID using a backend secret // You can find the secret in the website settings // Recommended to prevent spoofing verification: "hash", // optional metadata: { key: "value", amount: 100, allow_wire_transfer: true, }, }); ``` ## Identity verification Identity verification ensures that one person can't impersonate another. Identity verification requires you to add an hash (HMAC) (that you generate on your server using SHA256) to your installation snippet alongside your user ID and account ID. journy.io won't accept requests for a logged-in user without a valid hash. The hash is calculated using a secret key, which you should never share. Without this secret key, no third party can send journy.io a valid hash for one of your users, so they can't impersonate your users. This is optional but highly recommended. You can enable identify verification in the website settings in the connections view. ```js journy("identify", { userId: "userId", verification: "USER_ID_HMAC_VALUE_HERE" }) journy("account", { accountId: "accountId", verification: "ACCOUNT_ID_HMAC_VALUE_HERE" }) journy("event", { accountId: "accountId", verification: "ACCOUNT_ID_HMAC_VALUE_HERE" }) ``` ### PHP ```php { journy("screen", { name: "name" }); // or journy("pageview"); }, [location]); return ( // ... ); } ``` ### Vue Router You can use [`router.afterEach`](https://router.vuejs.org/guide/advanced/navigation-guards.html#global-after-hooks) to listen for route changes: ```js const router = new VueRouter({ ... }); router.afterEach((to, from) => { journy("screen", { name: "name" }); // or journy("pageview"); }); ``` Note: We don't accept a page URL argument for `journy("pageview")`. The current page URL will always be resolved using `window.location.href`. ## TypeScript We published an [npm package](https://www.npmjs.com/package/@journyio/web-types) with type definitions to enable type-safe usage of our JavaScript snippet. The code and documentation is available on [GitHub](https://github.com/journy-io/web-types). ## Localhost By default a site doesn't allow page views from other domains than the registered domain. This makes it difficult to test your tracking implementation locally. You can enable "Allow any domain" in the site settings to disable the domain check. This will allow you to test the JavaScript snippet with localhost as hostname. # Backend The journy.io API is organized around REST. Our API has predictable resource-oriented URLs, returns JSON-encoded responses, and uses standard HTTP response codes, authentication, and verbs. The API is hosted on api.journy.io. ## Official SDKs Our SDKs are designed to help you interact with our APIs with less friction. They are written in several different languages and help bridge the gap between your application and journy.io APIs. They take away the need to know the exact URL and HTTP method to use for each API call among other things leaving you more time to focus on making your application. | Language | Package | Source code | |------------|--------------------------------------------------------------------------------|----------------------------------------------------------------------------| | 💚 Node.js | [npm install @journyio/sdk ](https://www.npmjs.com/package/@journyio/sdk) | [github.com/journy-io/js-sdk](https://github.com/journy-io/js-sdk) | | 🐘 PHP | [composer require journy-io/sdk](https://packagist.org/packages/journy-io/sdk) | [github.com/journy-io/php-sdk](https://github.com/journy-io/php-sdk) | | 🐍 Python | [pip install journyio-sdk](https://pypi.org/project/journyio-sdk/) | [github.com/journy-io/python-sdk](https://github.com/journy-io/python-sdk) | | 💎 Ruby | Coming soon | Coming soon | Your favourite programming language not included? [Let us know!](mailto:hi@journy.io) In the meanwhile, you can use [OpenAPI Generator](https://github.com/OpenAPITools/openapi-generator) to generate a client for your programming language. ## Authentication The journy.io API uses API keys to authenticate requests. You can view and manage your API keys in the [connections screen](https://system.journy.io). Your API keys carry many privileges, so be sure to keep them secure! Do not share your secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth. All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail. For every request send to the API we expect a header `X-Api-Key` to be set with the API Key. ## Permissions When creating an API Key in [the application](https://system.journy.io) you will have the choice to give permissions to an API Key (which you can change later on). These permissions restrict the API Key from different actions. When an API Key tries to perform a certain action it doesn't have the permissions for, you will receive a `401: Unauthorized` response. ## Rate limiting To prevent abuse of the API there is a maximum throughput of 1800 requests per minute. If you need a higher throughput, please contact us. To keep our platform healthy and stable, we'll block API keys that consistently hit our rate limits. Therefore, please consider taking this throughput into account. In every response the headers `X-RateLimit-Limit` and `X-RateLimit-Remaining` will be set. The `X-RateLimit-Limit`-header will always contain the current limit of requests per minute. The `X-RateLimit-Remaining`-header will always contain the amount of requests you have left in the current sliding window. 💡 The client-side tracking uses different rate limits. ## Errors journy.io uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g. a required parameter was omitted). Codes in the 5xx range indicate an error with journy.io's servers (these are rare). When performing a `POST`- or `PUT`-request with a requestBody, or when including parameters, these parameters and fields will automatically be checked and validated against the API Spec. When any error occurs, you will get a response with an `errors`-field, structured as follows: ```json { "errors": { "parameters": { "header": { "headerParameterName": "Describe what's wrong with the header parameter.", ... }, "query": { "queryParameterName": "Describe what's wrong with the query parameter.", ... }, "path": { "pathParameterName": "Describe what's wrong with the path parameter.", ... }, }, "fields": { "fieldName": "Describe what's wrong with the fieldName.", "object.fieldName": "Describe what's wrong with the fieldName of the included object.", ... } } } ``` ## Best practices ### Track accounts & users immediately on creation When you create an account in your database, immediately sending data about that account to journy.io helps your team stay in sync. The same goes for users. Call [Upsert account](#operation/upsertAccount) as soon as possible, right after the account is first created in your database. ### Update account data daily Not every account is active every day. But, you may have properties on the account that change through background processing. That's why we recommend updating every one of your accounts' data in a recurring daily process. This way, you know that your accounts are updated every day in journy.io. ## Changelog ### December 2021 [POST /events](#operation/trackJourneyEvent) will be moved to [POST /track](#operation/trackEvent). [POST /events](#operation/trackJourneyEvent) is deprecated and will be removed in the future.

# Endpoint Structure All URLs are in the format: ```text https://api.jumpseller.com/v1/path.json?login=XXXXXX&authtoken=storetoken ``` The path is prefixed by the API version and the URL takes as parameters the login (your store specific API login) and your authentication token.

*** # Version The current version of the API is **v1**. If we change the API in backward-incompatible ways, we'll increase the version number and maintain stable support for the old urls.

*** # Authentication The API uses a token-based authentication with a combination of a login key and an auth token. **Both parameters can be found on the left sidebar of the Account section, accessed from the main menu of your Admin Panel**. The auth token of the user can be reset on the same page.  The auth token is a **32 characters** string. If you are developing a Jumpseller App, the authentication should be done using [OAuth-2](/support/oauth-2). Please read the article [Build an App](/support/apps) for more information.

*** # Curl Examples To request all the products at your store, you would append the products index path to the base url to create an URL with the format: ```text https://api.jumpseller.com/v1/products.json?login=XXXXXX&authtoken=XXXXX ``` In curl, you can invoque that URL with: ```text curl -X GET "https://api.jumpseller.com/v1/products.json?login=XXXXXX&authtoken=XXXXX" ``` To create a product, you will include the JSON data and specify the MIME Type: ```text curl -X POST -d '{ "product" : {"name": "My new Product!", "price": 100} }' "https://api.jumpseller.com/v1/products.json?login=XXXXXX&authtoken=XXXXX" -H "Content-Type:application/json" ``` and to update the product identified with 123: ```text curl -X PUT -d '{ "product" : {"name": "My updated Product!", "price": 99} }' "https://api.jumpseller.com/v1/products/123.json?login=XXXXXX&authtoken=XXXXX" -H "Content-Type:application/json" ``` or delete it: ```text curl -X DELETE "https://api.jumpseller.com/v1/products/123.json?login=XXXXXX&authtoken=XXXXX" -H "Content-Type:application/json" ```

*** # PHP Examples Create a new Product (POST method) ```php $url = 'https://api.jumpseller.com/v1/products.json?login=XXXXX&authtoken=XXXXX; $ch = curl_init($url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/json')); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "POST"); //post method curl_setopt($ch, CURLOPT_POSTFIELDS, '{ "product" : {"name": "My updated Product!", "price": 99} }'); $result = curl_exec($ch); print_r($result); curl_close($ch); ```

*** # Plain JSON only. No XML. * We only support JSON for data serialization. * Our node format has no root element. * We use snake_case to describe attribute keys (like "created_at"). * All empty value are replaced with **null** strings. * All API URLs end in .json to indicate that they accept and return JSON. * POST and PUT methods require you to explicitly state the MIME type of your request's body content as **"application/json"**.

*** # Rate Limit You can perform a maximum of: + 240 (two hundred forty) requests per minute and + 8 (eight) requests per second If you exceed this limit, you'll get a 403 Forbidden (Rate Limit Exceeded) response for subsequent requests. The rate limits apply by IP address and by store. This means that multiple requests on different stores are not counted towards the same rate limit. This limits are necessary to ensure resources are correctly used. Your application should be aware of this limits and retry any unsuccessful request, check the following Ruby stub: ```ruby tries = 0; max_tries = 3; begin HTTParty.send(method, uri) # perform an API call. sleep 0.5 tries += 1 rescue unless tries >= max_tries sleep 1.0 # wait the necessary time before retrying the call again. retry end end ``` Finally, you can review the Response Headers of each request: ```text Jumpseller-PerMinuteRateLimit-Limit: 60 Jumpseller-PerMinuteRateLimit-Remaining: 59 # requests available on the per-second interval Jumpseller-PerSecondRateLimit-Limit: 2 Jumpseller-PerSecondRateLimit-Remaining: 1 # requests available on the per-second interval ``` to better model your application requests intervals. In the event of getting your IP banned, the Response Header `Jumpseller-BannedByRateLimit-Reset` informs you the time when will your ban be reseted.

*** # Pagination By default we will return 50 objects (products, orders, etc) per page. There is a maximum of 100, using a query string `&limit=100`. If the result set gets paginated it is your responsibility to check the next page for more objects -- you do this by using query strings `&page=2`, `&page=3` and so on. ```text https://api.jumpseller.com/v1/products.json?login=XXXXXX&authtoken=XXXXX&page=3&limit=100 ```

*** # More * [Jumpseller API wrapper](https://gitlab.com/jumpseller-api/ruby) provides a public Ruby abstraction over our API; * [Apps Page](/apps) showcases external integrations with Jumpseller done by technical experts; * [Imgbb API](https://api.imgbb.com/) provides an easy way to upload and temporaly host for images and files.

***

# Just Eat API Just Eat offers services for our various business partners and our consumer applications. How you interact with the API depends on the services you wish to interact with. ## Security ### HTTPS All api calls and callbacks require HTTPS. Your service will need a valid SSL certificate and be accessible via the standard SSL port (port 443). ## Making an API request Some API calls require an API key, to authenticate the partner calling the API. ``` PUT https://uk-partnerapi.just-eat.io/orders/abcd1234 HTTP/1.1 Authorization: JE-API-KEY abcd123456789 ``` Other calls require a user token in the form of a JWT. ``` GET https://uk.api.just-eat.io/consumer/me/orders/uk HTTP/1.1 Authorization: Bearer abcd123456789 ``` ## Date Formats ### Date and time formats All dates and times should use the [ISO 8601 standard for representation of dates and times](https://en.wikipedia.org/wiki/ISO_8601). #### For instance: * DueDateWithUtcOffset: `"2015-05-26T14:52:35.5444292+01:00"` - Local time: `14:52` - UTC time: `13:52` - UTC offset: `+1hr` (due to daylight time saving) * DueDateWithUtcOffset: `"2015-02-03T11:10:00.0000000+00:00"` - Local time: `11:10` - UTC time: `11:10` - UTC offset: `0` (no daylight time saving, local time is equivalent to UTC) Note that the offset may be for a timezone different to your own, so you should alway convert to your own local time for display purposes (e.g. on receipts and terminals). ### Callback timestamps Timestamps sent to Just Eat should be recorded as the current local time (including any changes needed to account for daylight saving) with an accompanying offset that shows the difference between the recorded local time and the current UTC time. If it is not possible to record timestamps in local time, timestamps may be recorded in UTC time with a 00:00 offset. ## Async Webhooks Some of the webhooks on the platform are configured as being 'async' webhooks. These are for long-running operations, and work as follows: 1. Your webhook is invoked with a `?callback={returnUrl}` query string parameter. The `returnUrl` is a unique URL that you will need to send the async response to. 2. Return an immediate `202 Accepted` response from the webhook endpoint, to indicate that you have received the request. 3. Perform the long-running operation. This can be deemed either a _success_; or a _failure_. 4. If the result is a _**success**_, return the following: ``` POST {returnUrl} HTTP/1.1 { "status": "Success", "message": "{successMessage}", "data": {} // webhook-specific response object } ``` 5. Otherwise, if the result is a _**failure**_, return the following: ``` POST {returnUrl} HTTP/1.1 { "status": "Failure", "message": "{failureMessage}", "data": {} // webhook-specific response object } ```

The payments API is used to create a session to offer Klarna's payment methods as part of your checkout. As soon as the purchase is completed the order should be read and handled using the [`Order Management API`](https://docs.klarna.com/api/ordermanagement). Read more on [Klarna payments](https://docs.klarna.com/klarna-payments/).

This is the koomalooma Partner API. koomalooma is the first Loyalty BPaaS (Business Process as a Service) for mobile and web companies. With koomalooma merchants issue points for actions their customers / users make on your mobile or web store, for example a purchase or a referral. koomalooma takes care of all the rest, from signing up users, keeping track of points and delivering rewards in over 80 countries. koomalooma offers an easy to integrate API and web backend to configure loyalty campaigns and track performance. You can find more at http://support.koomalooma.com