Partnerize Partners API
REST API for publishers and partners to manage campaigns, tracking links, commissions, payments, reporting, and analytics across the Partnerize network.
REST API for publishers and partners to manage campaigns, tracking links, commissions, payments, reporting, and analytics across the Partnerize network.
openapi: 3.0.1
info:
title: Partnerize Partners API
version: 1.4.99
description: "# Introduction\n\nThis is the full external API documentation for\
\ the [Partnerize](http://partnerize.com/) API. The API is organised around REST\
\ principles like resource-oriented URLs and uses standard HTTP features like\
\ response codes, verbs and Authentication. At Partnerize, we build features API-first\
\ and have built our web application on top of the API as we want to make our\
\ core functionality available to developers to consume programmatically.\n\n\
You can refer to the API reference for a full list of supported endpoints. If\
\ it is the first time you are using the API, go to the [_Quick Start_](#section/Quick-Start)\
\ section for a quick start tutorial on making your first API call.\n\n# Versioning\n\
\n Currently there are three global versions of the Partnerize API. You can distinguish\
\ between them by looking at the endpoint URL. First version endpoints do not\
\ include a version in the path: e.g. `https://api.partnerize.com/network/`. Second\
\ and third version endpoints can be identified by the `v2` and `v3` in the URL:\
\ e.g. `https://api.partnerize.com/v2/campaigns/{campaignId}/commissions` or `https://api.partnerize.com/v3/brand/campaigns/{campaignId}/conversions/bulk`.\
\ \n Since the versions are global, there are common conventions that apply to\
\ all API versions as well as version specific ones. The sections below describe\
\ these conventions in detail.\n\n# Quick Start\n\nThis tutorial takes you through\
\ creating your first Partnerize API call. The example below demonstrates how\
\ to:\n\n1. Obtain your API keys\n2. Generate an Authorization header\n3. Make\
\ your first Partnerize API request\n\n*Step 1.* Obtaining your API keys\n\n1.\
\ Login to the Partnerize console at [https://console.partnerize.com](https://console.partnerize.com/).\n\
2. Go to Settings – the _User Application Key_ and User _API key_ can be found\
\ under Account settings.\n\n*Step 2.* Generate an Authorization header\n\nAuthentication\
\ is achieved by providing an Authorization header in the following format:\n\n\
`Authorization: Basic cDN0ZXcxNDV5M3RhZzQxbjowaHkzNGho`\n\nWhere `cDN0ZXcxNDV5M3RhZzQxbjowaHkzNGho`\
\ is the Base64 encoding of the _User Application Key_ and _User API key_ joined\
\ by a colon ':'.\n\nRefer to the [_Access and Authentication_](#section/Common-API-Conventions/Access-and-Authentication)\
\ section for more details.\n\n*Step 3.* Make your first Partnerize API request\n\
\nIn this step you are going to make a call to the "Networks" endpoint\
\ to retrieve a list of all networks your user has access to.\n\nIn the example\
\ below, replace the {personal\\_token} with the one generated in the previous\
\ step:\n\n`curl -X GET https://api.partnerize.com/network -H 'Authorization:\
\ Basic {personal_token}'`\n\nThe response will contain a collection of networks:\n\
\n```\n{\n \"count\": 1,\n \"execution_time\": \"0.20239 seconds\",\n \
\ \"networks\": [\n {\n \"network\": {\n \"\
network_id\": 1,\n \"network_name\": \"Partnerize\",\n \
\ \"network_description\": \"Test Network\",\n \"network_notes\"\
: \"This is a test Partnerize network\",\n \"network_application_id\"\
: 2,\n \"auto_approve_publishers\": \"n\",\n \"\
default_campaign_id\": null,\n \"cm_client_id\": “b4d0d85cff813cdce092c261b2b200”,\n\
\ \"network_contact_email\": null,\n \"network_locale\"\
: \"en\"\n }\n }\n ]\n}\n``` \n\n# API Change Management\
\ Policy\n\n## Types of changes\n\n### Backwards-compatible changes\n\nConsumers\
\ of the Partnerize API should ensure that their applications can handle backwards-compatible\
\ changes. Examples of what Partnerize considers to be backwards-compatible changes:\n\
\n* Introducing new resources\n* Introducing new optional request parameters to\
\ existing API resources\n* Introducing new properties in the responses of existing\
\ API resources\n* Introducing new methods to existing API resources\n* Introducing\
\ new headers to existing responses\n* Changing the order of existing response\
\ properties\n\nPartnerize will be making backwards-compatible changes without\
\ advanced notice. The changes will be communicated by updating the API documentation.\
\ \n\n### Breaking changes\n\nBreaking changes would usually require changes in\
\ the code of a Partnerize API consumer. Examples of what Partnerize considers\
\ to be breaking changes:\n\n* Removing a resource (see _API Resource Deprecation_\
\ below)\n* Removing or renaming properties in existing responses\n* Removing\
\ documented response headers\n* Introducing new mandatory request parameters\
\ or header\n* Making an optional request parameter or header to mandatory\n\n\
Partnerize will announce breaking changes at least 3 months in advance. \n\n\
### Hotfix changes\n\nPartnerize may introduce either breaking or backwards-compatible\
\ changes if required to address stability or security issues. In the rare situation\
\ of that happening Partnerize reserves the right to make those changes without\
\ the agreed minimum notice period announcement. \n\n## API resource deprecation\n\
\nPartnerize will give API consumers at least 3 months notice about deprecating\
\ an API resource. Partnerize will notify affected consumers via email with instructions\
\ about the upgrade process. Once the announcement is made the resource will\
\ be marked as `Obsolete` in the API documentation together with an alternative\
\ new functionality to use. \n\n# Common API Conventions\n\n## Terminology\n\n\
Older API endpoints may refer to _Brands_ as _Advertisers_ and _Partners_ as _Publishers_.\
\ Those terms are used interchangeably throughout the API reference. The reference\
\ in this set of documents is the single source of truth for the interface specification.\
\ \n\n## Access and Authentication\n\nThe Partnerize API uses HTTP Basic Authentication.\
\ You must have valid application\\_key and user\\_api\\_key to make API requests.\
\ Refer to the [_Quick Start_](#section/Quick-Start) tutorial for details on how\
\ to obtain these. The application\\_key identifies the Network you are making\
\ the request against and the user\\_api\\_key identifies the User on whose behalf\
\ the request is made. The keys are sent as part of an _Authorization_ header\
\ which value contains the word Basic followed by space and a base-64-encoded\
\ string *username:password*, where:\n\n- username: *application\\_key*\n- password:\
\ *user\\_api\\_key*\n\n `Authorization: Basic cDN0ZXcxNDV5M3RhZzQxbjowaHkzNGho`\n\
\nAccess to data and operations of certain endpoints is dependent on the access\
\ rights of the user. \n\n## Requests\n\nAll API requests must be made over [HTTPS](https://en.wikipedia.org/wiki/HTTPS)\
\ and contain a valid Authorization header value.\n\n## Standard Pagination\n\n\
Certain endpoints will generate large result sets. To save bandwidth and long\
\ processing times, these endpoints will paginate the results to reduce the strain\
\ on both client and server.\n\nAny endpoint that supports pagination will return\
\ 3 attributes to support this:\n\n- `offset` the current offset of the data returned\n\
- `limit` the number of results to which the output was restricted\n- `count`\
\ the total number of results available\n\nIf `offset` combined with `limit` is\
\ less than the overall count, the results have been truncated. Therefore, to\
\ consume all data you will need to page through the result set.\n\n### Paging\n\
\nTo paginate through a result set, you can use a combination of 2 parameters:\n\
\n| **Parameter** | **Description** | **Notes** |\n| --- | --- | --- |\n| `offset`\
\ | Offset the results by a given amount | Integer, defaults to `0` |\n| `limit`\
\ | Limit the number of results returned | Integer, maximum limit is defined in\
\ result set headers |\n\nFor example, if an endpoint produces 500 results, only\
\ the first 300 will be returned (results `0` to `299`). In order to retrieve\
\ the remaining results, implement the `offset` GET param. In this example, adding\
\ `offset=300` to the query string parameters.\n\nThere are 2 considerations when\
\ doing this:\n\n- Results begin at `offset 0`. If you're retrieving a report\
\ with `limit=300`, page 2 will begin at `offset=300`, page 3 at `offset=600`,\
\ page 4 at `offset=900`, etc.\n- The reports you generate are based on live data,\
\ and could be subject to continuous, incremental changes. If your query covers\
\ a particularly busy data set, then data inserts or updates may occur between\
\ paging.\n\n### Hypermedia\n\nIt can be cumbersome to manage pagination programmatically,\
\ especially when attempting to rapidly prototype. To provide some helpful assistance,\
\ the API will output a `hypermedia` node for all paginated result sets. Essentially\
\ this performs all necessary calculations and outputs all relevant information\
\ with absolute URI's to assist easier pagination.\n\n```\n\"hypermedia\"\
: {\n \"pagination\": {\n \"total_page_count\": 15,\n \"total_item_count\"\
: 51234,\n \"first_page\": \"/user.json?limit=100&offset=0\",\n \
\ \"last_page\": \"/user.json?limit=100&offset=1400\",\n \"next_page\"\
: \"/user.json?limit=100&offset=100\",\n \"previous_page\": null\n }\n\
}\n```\n\n## Cursor Pagination\n\nFor the granular conversion reporting endpoint,\
\ we have adopted cursor based pagination. Due to the scale of some clients, there\
\ is a large overhead involved in processing the offset and computing the total\
\ number of results. This overhead compounds as the data set size increases, and\
\ when the data set grows large enough it becomes impractical to perform the task\
\ in real time.\n\nTo ensure these high volume endpoints can scale, cursor based\
\ pagination has been implemented, where each response will now return a `cursor_id`\
\ attribute along with the results. This indicates where the client is currently\
\ within the result set. When the client requests another page, and includes the\
\ `cursor_id` value, the server will be able to determine where the client is\
\ up to in the result set and send the appropriate items.\n\nThis approach does\
\ not suffer from the same overhead drawbacks that limit/offset pagination does,\
\ and provides a consistent view of the result set across pages.\n\n### Paging\n\
\nTo paginate through a result set, you can use a combination of 2 parameters:\n\
\n| **Parameter** | **Description** | **Notes** |\n| --- | --- | --- |\n| `cursor_id`\
\ | Cursor value that defines client position in result set | Integer |\n| `limit`\
\ | Limit the number of results returned | Integer, maximum limit is 300 |\n\n\
For example, if an endpoint produces 5,000 results, only the first 300 will be\
\ returned (results 0 to 299). Within the header attributes, a `cursor_id` will\
\ be included. Simply pass the `cursor_id` in conjunction with the desired limit\
\ to return the subsequent items from the result set.\n\n### Hypermedia\n\nThe\
\ hypermedia object has been updated to automatically include the relevant `cursor_id`\
\ and limit for the next page.\n\n```\n\"hypermedia\": {\n \"pagination\":\
\ {\n first_page: \"/reporting/report_publisher/publisher/10l1/conversion.json?start_date=2018-03-01+00%3A00%3A00&end_date=2018-04-01+00%3A00%3A00&limit=300\"\
,\n next_page: \"/reporting/report_publisher/publisher/10l1/conversion.json?start_date=2018-03-01+00%3A00%3A00&end_date=2018-04-01+00%3A00%3A00&limit=300&cursor_id=10325942995\"\
\n }\n}\n```\n\n## Rate Limits\n\nTo protect our API users, API endpoints will\
\ rate limit based on usage.\nIf violated, the API will respond with with a 429\
\ http status code with the following body:\n\nv1 API:\n\n {\n \"error\"\
: {\n \"message\": \"Too Many Requests\",\n \"type\": \"\
429\"\n }\n }\n\nv2 API:\n\n {\n \"error\": {\n \"errors\"\
: [\n ],\n \"code\": \"429\",\n \"message\": \"Too Many Requests\"\
\n }\n }\n\nv3 API:\n\n {\n \"error\": {\n \"errors\":\
\ [\n {\n \"property\": \"\",\n \"message\": \"\
You have made too many requests recently, please try again later.\",\n \
\ \"code\": \"3b22ff00-96a5-4fa4-96cc-f36e68dbd2e2\",\n \"type\"\
: \"too_many_requests\"\n }\n ],\n \"message\": \"Too Many\
\ Requests\",\n \"code\": \"429\"\n }\n }\n\nTo help monitor your\
\ API usage, the following headers will be returned via the API to help moderate\
\ the integration:\n\n| Code | Data Type | Description \
\ |\n|-------------------------|-----------|-------------------------------------------------------|\n\
| `X-RateLimit-Limit` | integer | How many tokens are permitted \
\ |\n| `X-RateLimit-Remaining` | integer | How many tokens\
\ are left in the specified time period |\n| `X-RateLimit-Reset` | integer\
\ | How many seconds until the throttle resets itself |\n| `X-RateLimit-Retry-After`\
\ | integer | How mow many seconds to wait to retry |\n\n# Version\
\ 1 API Conventions\n\n## Requests\n\n### Base URL\n\nThe base URL for version\
\ 1 API endpoints is [https://api.partnerize.com/](https://api.partnerize.com/)\n\
\n## Response Formats\n\nThe default response format is JSON. You can specify\
\ the response format of each request, by adding a file extension suffix to the\
\ end of the request URI. The requested format will dictate the HTTP Content-Type\
\ header that is returned in the response. Currently, there are 3 available formats:\n\
\n| **Format** | **Header** | **Notes** |\n| --- | --- | --- |\n| `.json` | `Content-Type:\
\ application/json` | |\n| `.xml` | `Content-Type: text/xml` | |\n| `.csv`\
\ | `Content-Type: application/octet-stream` | Only available on specific endpoints\
\ |\n\n\n## Rate limit response\nWhenever too many requests are sent through within\
\ a period of time the response will be an error with an http status code 429\
\ Too Many Requests. See [Rate limits](#section/Common-API-Conventions/Rate-Limits)\
\ for more information on this.\n\n\n**Sample JSON response body when a rate limit\
\ is hit.**\n```\n{\n \"error\": {\n \"message\": \"Too Many\
\ Requests\",\n \"type\": \"429\"\n }\n }\n```\n\n## Compression\n\
\nThe API is compression-enabled. To control whether the API response is compressed,\
\ send the relevant `Accept-Encoding` HTTP header:\n\n- Request: `Accept-Encoding:\
\ gzip`\n- Response: `Content-Encoding: gzip`\n\n# Version 2 API Conventions\n\
\n## Requests\n\n### Base URL\n\nThe base URL for version 2 API endpoints is [https://api.partnerize.com/v2](https://api.partnerize.com/v2).\n\
\n### Supported HTTP Verbs\n\nPartnerize's API uses appropriate HTTP verbs\
\ where possible. Endpoints support one or more of the following HTTP verbs:\n\
\nGET – GET requests retrieve one or more entities and are always read-only. A\
\ successful request returns a response with a 200 _OK_ status code.\n\nPOST –\
\ POST requests are mainly are used to create Partnerize entities or batch operations.\
\ When successful such a request returns a 201 _Created_ response code. In the\
\ cases when the POST request is used for batch operations processing is done\
\ asyncronously. In those cases the successful request will return a 202 _Accepted_\
\ response code and the response should contain a job id, which can be used to\
\ monitor the status of the processing. \n\nPUT – PUT request update the resource\
\ provided in the URL. PUT requests are idempotent and result in the resource\
\ being replaced. A successful request returns a response with a 200 _OK_ status\
\ code.\n\nPATCH – Used to do partial updates to Partnerize entities. A successful\
\ request returns a response with a 200 _OK_ status code.\n\nDELETE – DELETE requests\
\ can be used to remove an entity when supported. A successful request returns\
\ a response with a 200 _OK_ or a 204 _No Content_ status code.\n\nIf an endpoint\
\ doesn't support a particular method, it will return a response with a 405\
\ _Method Not Allowed_ code.\n\n## Responses\n\nVersion 2 API endpoints return\
\ response data as a JSON object. Refer to the API reference for details of each\
\ endpoint responses. The response will include one of the following HTTP status\
\ codes:\n\n### HTTP Status Codes Summary\n\n| **HTTP Status Code** | **Description**\
\ |\n| --- | --- |\n| `200 OK` | The request was successfully completed. A 200\
\ status is returned for a successful GET, PUT, PATCH and sometimes DELETE methods.\
\ |\n| `201 Created` | The request was successful and a resource was created.\
\ The response usually includes an identifier for the newly created resource.\
\ |\n| `202 Accepted` | Some of the requests, e.g. bulk are handled by background\
\ jobs. This response status code indicates that the request was received and\
\ handed over for processing.|\n| `204 No content` | The request was successfully\
\ completed and there is no payload in the response. |\n| `400 Bad Request` |\
\ The request could not be processed because it contains missing or invalid information.\
\ See [Errors](#section/Version-2-API-Conventions/Errors) for more details. |\n\
| `401 Unauthorized` | The request is not authorized. The request could not be\
\ authenticated becuase of wrong or invalid credentials used in the Authorization\
\ header. |\n| `403 Forbidden` | The user is not authorized to perform this action.\
\ |\n| `404 Not Found` | The request includes a resource URI that cannot be found\
\ by the server. |\n| `405 Method Not Allowed` | The request method, e.g. POST,\
\ is not allowed for the resource identified by the request URI. |\n| `429 Too\
\ Many Requests` | The user has exceeded the quota for a particular request. See\
\ [Rate limits](#section/Common-API-Conventions/Rate-Limits) for more information\
\ on this. |\n| `500 Internal Server Error` | Generic server error. The server\
\ encountered an unexpected condition that prevented it from fulfilling the request.\
\ |\n| `503 Internal Server Error` | The service is temporarily unavailable. |\n\
\nSee the [Errors](#section/Version-2-API-Conventions/Errors) section below for\
\ more details on error responses.\n\n### Response format\n\n#### Top level attributes\n\
\nEach response document contains an `execution_time` top level attribute. \n\n\
#### Collections response\n\nIn addition to the `execution_time` top level attribute,\
\ a collection response contains a `count` one, which represents the total number\
\ of resources in the collection.\n\nExample:\n\n```\n{\n \"execution_time\"\
: \"1.11761 seconds\",\n \"count\": 0,\n \"commissions\": []\n}\n``` \n\n\
#### Single resource response\n\nExample:\n\n```\n{\n \"execution_time\": \"\
1.11761 seconds\",\n \"commission\": {\n \"id\": '1234',\n }\n}\n```\
\ \n\n## Errors\n\nThe Version 2 API uses the above mentioned standard HTTP status\
\ codes to indicate the success or failure of the API calls.\nThe body of the\
\ response will be JSON in the following format:\n\n```\n{\n \"error\": {\n \
\ \"errors\": [\n {\n \"property\": \"evaluation_period\",\n \
\ \"type\": \"validation_error\",\n \"code\": \"required_property\"\
,\n \"message\": \"Parameter 'evaluation_period' is required\"\n }\n\
\ ],\n \"code\": \"400\",\n \"message\": \"Bad Request\"\n }\n}\n```\n\
\n| Attribute | Type | Description |\n|-----------|---|-------|\n| `errors` |\
\ array | An array of error(s) which occured which triggered the error. Each item\
\ contains the following attributes;<br />`property` - The attribute the error\
\ is related to.<br />`message` - A human-friendly message describing the error.<br\
\ />`code` - A unique code for this type of error.<br />`type` - A text based\
\ error classification. |\n| `code` | string | An error code representing the\
\ error(s) which has occured, this typically matches the HTTP status code. |\n\
| `message` | string | A human-friendly message describing the error(s) which\
\ has occured. |\n\n### Bad Request (Code 400)\nIf there is an error in your input,\
\ you’ll receive a “400 Bad Request” http response. The body of the response will\
\ be JSON with the `errors` attribute containing an array of details of the error(s).\n\
\n| Code | Description |\n|--|--|\n| `invalid_property_format` | Invalid date\
\ format. |\n| `invalid_type` | Invalid parameter type. For example when an array\
\ is expected and the input was different type. |\n| `invalid_value` | The value\
\ is out of bounds. |\n| `required_property` | Missing parameter. |\n| `invalid_lower_bound`\
\ | The value is too low. |\n| `invalid_upper_bound` | The value is too hogh.\
\ |\n| `invalid_enum_value` | The value must be one of a specified list of values.\
\ |\n| `invalid_max_length` | Maximum number of characters reached. |\n| `invalid_property`\
\ | The property is invalid. |\n\n### Unauthorized (Code 401)\nIf there is an\
\ error with your authentication credentials, you’ll receive a “401 Unauthorized”\
\ http response. \n\n**Sample JSON response body**\n```\n{\n \"error\": {\n \
\ \"errors\": [\n {\n \"type\": \"error\",\n \"code\": \"\
unauthorized\",\n \"message\": \"Your API credentials can be found in Account\
\ settings. 'Username' will be your 'User application key' and 'Password' will\
\ be your 'User API key'\"\n }\n ],\n \"code\": \"401\",\n \"message\"\
: \"Unauthorized\"\n }\n}\n```\n\n### Forbidden (Code 403)\nIf there is an denial\
\ of access to a resouce within your request, you’ll receive a “403 Forbidden“\
\ http response. \n\n```\n{\n \"error\": {\n \"errors\": [\n {\n \
\ \"type\": \"error\",\n \"code\": \"unauthorized\",\n \"message\"\
: \"You do not have 'read' permission on campaign with id '1'\"\n }\n \
\ ],\n \"code\": \"403\",\n \"message\": \"Forbidden\"\n }\n}\n```\nWhen\
\ the user is not allowed to know the resource exists, i.e. they don't have READ\
\ permission on the resource, the response will have a `404 Not Found` status\
\ code.\n\n### Not Found (Code 404)\nIf there is an error locating a requested\
\ resource, you’ll receive a “404 Not Found\" http response. \n\n\n**Sample JSON\
\ response body when an invalid URL has been requested.**\n```\n{\n \"error\"\
: {\n \"errors\": [\n {\n \"type\": \"error\",\n \"code\"\
: \"entity_not_found\",\n \"message\": \"campaign not found for id '1'\"\
\n }\n ],\n \"code\": \"404\",\n \"message\": \"Not Found\"\n }\n\
}\n```\n\n### Method Not Allowed (Code 405)\nIf there is an error accessing a\
\ resource using the given HTTP verb, you’ll receive a “405 Method Not Allowed“\
\ http response. The body of the response will be JSON with the `errors` attribute\
\ containing an array of details of the error(s).\n\n\n**Sample JSON response\
\ body when an valid URL has been requested with an invalid request method.**\n\
```\n{\n \"error\": {\n \"errors\": [\n {\n \"type\": \"error\"\
,\n \"code\": \"routing_error\",\n \"message\": \"index not supported\"\
\n }\n ],\n \"code\": \"405\",\n \"message\": \"Method Not Allowed\"\
\n }\n}\n```\n\n### Too Many Requests (Code 429)\nThis error code indicates that\
\ too many requests were sent within a period of time. See [Rate limits](#section/Common-API-Conventions/Rate-Limits)\
\ for more information on this.\n\n\n**Sample JSON response body when a rate limit\
\ is hit.**\n```\n\n {\n \"error\": {\n \"errors\": [\n \
\ ],\n \"code\": \"429\",\n \"message\": \"Too Many Requests\"\n\
\ }\n }\n ``` \n\n## Date Time\n\n`v2` API endpoints use [ISO-8601](https://www.iso.org/iso-8601-date-and-time-format.html)\
\ date time format.\n\n### Example:\n\n`2019-03-01T12:01:00+00:00` - this example\
\ represents 1 minute past midday on the 1st of March 2019 in UTC.\n\n`2019-03-01`\
\ - date only example\n\n# Version 3 API Conventions\n\n## Requests\n\n### Base\
\ URL\n\nThe base URL for version 3 API endpoints is [https://api.partnerize.com/v3](https://api.partnerize.com/v3).\
\ Version 3 of the API endpoints introduces _brands_ and _partners_ context to\
\ the API. This means that the _brand_ endpoints will have the following base\
\ URL: [https://api.partnerize.com/v3/brand](https://api.partnerize.com/v3/brand)\
\ and the _partner_ ones will have: [https://api.partnerize.com/v3/partner](https://api.partnerize.com/v3/partner)\n\
\n### Supported HTTP Verbs\n\nPartnerize's API uses appropriate HTTP verbs\
\ where possible. Endpoints support one or more of the following HTTP verbs:\n\
\nGET – GET requests retrieve one or more entities and are always read-only. A\
\ successful request returns a response with a 200 _OK_ status code.\n\nPOST –\
\ POST requests are mainly are used to create Partnerize entities or batch operations.\
\ When successful such a request returns a 201 _Created_ response code. In the\
\ cases when the POST request is used for batch operations processing is done\
\ asyncronously. In those cases the successful request will return a 202 _Accepted_\
\ response code and the response should contain a job id, which can be used to\
\ monitor the status of the processing. \n\nPUT – PUT request update the resource\
\ provided in the URL. PUT requests are idempotent and result in the resource\
\ being replaced. A successful request returns a response with a 200 _OK_ status\
\ code.\n\nPATCH – Used to do partial updates to Partnerize entities. A successful\
\ request returns a response with a 200 _OK_ status code.\n\nDELETE – DELETE requests\
\ can be used to remove an entity when supported. A successful request returns\
\ a response with a 200 _OK_ or a 204 _No Content_ status code.\n\nIf an endpoint\
\ doesn't support a particular method, it will return a response with a 405\
\ _Method Not Allowed_ code.\n\n### Unrecognized request headers and parameters\n\
\n* We ignore unrecognized HTTP headers.\n* We ignore unrecognized query string\
\ parameters.\n* We return a 400 _Bad Request_ if there are unrecognized parameters\
\ in the request body.\n\n## Responses\n\nVersion 3 API endpoints return response\
\ data as a JSON object. Refer to the API reference for details of each endpoint\
\ responses. The response will include one of the following HTTP status codes:\n\
\n### HTTP Status Codes Summary\n\n| **HTTP Status Code** | **Description** |\n\
| --- | --- |\n| `200 OK` | The request was successfully completed. A 200 status\
\ is returned for a successful GET, PUT, PATCH and sometimes DELETE methods. |\n\
| `201 Created` | The request was successful and a resource was created. The response\
\ usually includes an identifier for the newly created resource. |\n| `202 Accepted`\
\ | Some of the requests, e.g. bulk are handled by background jobs. This response\
\ status code indicates that the request was received and handed over for processing.|\n\
| `204 No content` | The request was successfully completed and there is no payload\
\ in the response. |\n| `400 Bad Request` | The request could not be processed\
\ because it contains missing or invalid information. See [Errors](#section/Version-3-API-Conventions/Errors)\
\ for more details. |\n| `401 Unauthorized` | The request is not authorized. The\
\ request could not be authenticated becuase of wrong or invalid credentials used\
\ in the Authorization header. |\n| `403 Forbidden` | The user is not authorized\
\ to perform this action. |\n| `404 Not Found` | The request includes a resource\
\ URI that cannot be found by the server. |\n| `405 Method Not Allowed` | The\
\ request method, e.g. POST, is not allowed for the resource identified by the\
\ request URI. |\n| `429 Too Many Requests` | The user has exceeded the quota\
\ for a particular request. See [Rate limits](#section/Common-API-Conventions/Rate-Limits)\
\ for more information on this. |\n| `500 Internal Server Error` | Generic server\
\ error. The server encountered an unexpected condition that prevented it from\
\ fulfilling the request. |\n| `503 Internal Server Error` | The service is temporarily\
\ unavailable. |\n\nSee the [Errors](#section/Version-3-API-Conventions/Errors)\
\ section below for more details on error responses.\n\n### Response format\n\n\
#### Top level attributes\n\nEach response document contains a `data` top level\
\ attribute and may contain a `hypermedia` one. The `data` attribute wraps all\
\ response data in the payload, while `hypermedia` will contain links to related\
\ resources. \n\nExample:\n\n```\n{\n \"data\": {\n \"id\": \"111111l11\"\
,\n ...\n },\n \"hypermedia\": {\n \"links\": {\n \"tasks\":\
\ \"/v3/jobs/111111l11/tasks\"\n }\n }\n}\n``` \n\n\n## Errors\nThe API uses\
\ standard HTTP status codes to indicate the success or failure of the API call.\n\
The body of the response will be JSON in the following format:\n\n```\n{\n \"\
error\": {\n \"errors\": [\n {\n \"property\": \"[name]\",\n \
\ \"message\": \"The attribute expected to be of type 'string' but 'integer'\
\ given.\",\n \"code\": \"6a6c32c0-de05-4301-89dd-4a72133c137f\",\n \
\ \"type\": \"validation_error\"\n }\n ],\n \"code\": \"400\",\n\
\ \"message\": \"Bad Request\"\n }\n}\n```\n\n| Attribute | Type | Description\
\ |\n|-----------|---|-------|\n| `errors` | array | An array of error(s) which\
\ occured which triggered the error. Each item contains the following attributes;<br\
\ />`property` - The attribute the error is related to.<br />`message` - A human-friendly\
\ message describing the error.<br />`code` - A unique code for this type of error.<br\
\ />`type` - A text based error classification. |\n| `code` | string | An error\
\ code representing the error(s) which has occured, this typically matches the\
\ HTTP status code. |\n| `message` | string | A human-friendly message describing\
\ the error(s) which has occured. |\n\n### Bad Request (Code 400)\nIf there is\
\ an error in your input, you’ll receive a “400 Bad Request” http response. The\
\ body of the response will be JSON with the `errors` attribute containing an\
\ array of details of the error(s).\n\n| Code | Description |\n|--|--|\n| `2572f7f9-e87e-4aa7-98cf-6f53c9ed5584`\
\ | A value is required for an attribute which has not been supplied. |\n| `901d8596-1b91-4e87-869f-ef66bd4ffc0c`\
\ | The value contains more items than expeceted. |\n| `b9f3a79a-6767-4947-907e-5e0934b5a641`\
\ | The value contains more attributes than expected. |\n| `6771735c-3000-49d1-a978-74aeb33d15b9`\
\
# --- truncated at 32 KB (453 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/partnerize/refs/heads/main/openapi/partnerize-partners-api-openapi.yml