Partnerize Partners API

REST API for publishers and partners to manage campaigns, tracking links, commissions, payments, reporting, and analytics across the Partnerize network.

OpenAPI Specification

partnerize-partners-api-openapi.yml Raw ↑
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&#39;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&#39;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