# 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
Check texts for style and grammar issues with LanguageTool. Please consider the following default limitations:
- your daily request limit depending on your plan
- maximum number of requests per minute: 20 (free) / 80 (Premium)
- maximum number of characters per minute: 75,000 (free) / 300,000 (Premium)
- maximum number of characters per request: 20,000 (free) / 60,000 (Premium)
- for the free version, also consider the limitations documented here
- Note: any parameters or outputs not part of this documentation are internal and must not be relied on
The REST API for LGTM provides data so that you can customize how you integrate LGTM analysis into your workflow. It includes the following resources: * `/` ([API root](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-API-root))—get version information or download the specification in OpenAPI format. * `/projects` ([Projects](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-Projects))—list projects, get a summary of the current status for a project, or add new projects. * `/analyses` ([Analyses](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-Analyses))—get a summary of results, download all the alerts, or trigger analysis for a specific commit. * `/codereviews` ([Code reviews](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-Code-reviews))—trigger code review for a patch, and view the results. * `/operations` ([Operations](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-Operations))—get information about long-running tasks, for example, analyses or code reviews that you've requested. * `/snapshots` ([Snapshots](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-Snapshots))—download and upload databases representing a snapshot of a codebase. * `/queryjobs` ([Query jobs](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-Query-jobs))—submit queries to evaluate against existing projects, and download their results. * `/system` ([System](https://lgtm.com/help/lgtm/api/api-v1#LGTM-API-specification-System))—get information on the health or usage of the system. For an overview and getting started topics, see [API for LGTM](https://lgtm.com/help/lgtm/api/api-for-lgtm).