openapi: 3.2.0 info: title: Paperless Parts Events API description: 'The Paperless Parts API provides access to your data, enabling developers to easily integrate Paperless Parts with third-party systems, such as Customer Relationship Management (CRM) and Enterprise Resource Planning (ERP) tools. The API is designed to support two primary use case. First, reading all information associated with a particular order or quote for import into another system. Second, managing customer data, either for an initial bulk import or for on-going synchronization with an external database. ## Authorization ## Requests are authorized via an API key. Administrators of a Paperless Parts account can generate an API Token which grants access to all of the endpoints documented here. The token obtained from the application must be added to the header of all requests using the key `"Authorization"` with the value `"API-Token "`, where `` is your Paperless Parts API Token. You can use the "Execute" button in an endpoint''s documentation on this page to try out the endpoint. This will send a request to the endpoint on the Paperless Parts server and display the result on this page. Before doing so, however, you''ll need to click on the ''Authorize'' button at the top of the screen, and in the "Value" field enter `"API-Token "`, where `` is your API token as described above. ## Overview ## The API endpoints are organized around REST. API calls should be made to the `https://api.paperlessparts.com` base domain. URLs are designed to clearly describe an entity or collection of entities. HTTP verbs typically describe whether entities are being read, created, modified, or deleted. Where applicable, request and response bodies are in JSON format. Standard HTTP response codes, in addition to error messages, are used to help explain request failures. ### Associations Many entities in the API data model are associated with other entities. As a guiding principle, `GET` requests that fetch data nest associated entities in the JSON response. However, when creating or modifying entities, a flat (non-nested) object must be provided, as explained in the documentation for each endpoint. Associations are specified when writing data by using entity IDs in fields ending in `_id`. For example, consider the relationship where a Company has many Customers. When fetching a Customer via a `GET` request, the associated Company will be nested as an object with key `company` in the response. When creating a Customer, the Company is specified via its integer id using the key `company_id`. ### Events Overview Events are a way of logging relevant actions that are taken within your account. For instance, when you create a new quote, Paperless Parts logs a `quote.created` event, and once you send that quote, we log another `quote.sent` event. These logs offer you a trail of data that you can use to keep integrations in sync. By polling for new events, you can maintain an up-to-date record of what actions Paperless Parts has initiated that your integration has not. For instance, you could poll for `part.interrogation_succeeded` events and send out a notification upon receiving one. ### HTTP Methods The API endpoints support different HTTP methods depending on whether records are being read, created, or updated. To read an entity, use `GET`. To create a new entity, use `POST`. To modifying an entity, use `PATCH`. Note, `PATCH` is used rather than `PUT` to indicate that entities can be partially updated. In other words, in general, if a field is omitted from a `PATCH` request, that field''s value will stay the same (rather than be set to `null`). All fields requiring values are required to be included in `POST` requests. > Note: Endpoints with a documented `PATCH` method can generally be used with a `PUT` method. The `PUT` is implemented as a partial update (as opposed to a replacement) and is supported for maximum compatibilty. For example, consider the `email` field on the Customer entity, which is required. All Customers must have a non-null `email`. When creating a Customer via `POST`, the request body must contain an `email` key and its value cannot be `null` (other validation applies to that field, as well, including a valid email format and a unique value). When editing a Customer via `PATCH` request, it is not necessary to include an `email` key in the request body. If `email` is omitted, the existing email address will not be changed. If you send a `PATCH` request with `email=null`, then you will receive an error response indicating that a value for `email` is required.' version: '1.0' termsOfService: https://www.paperlessparts.com/web-service-agreement/ contact: name: Paperless Parts url: https://www.paperlessparts.com email: support@paperlessparts.com servers: - url: '{url}/{version}' variables: url: default: https://api.paperlessparts.com version: default: v1 security: - app_id: [] tags: - name: Events description: Endpoints for viewing communications between Paperless Parts and ERP integrations paths: /events/public: get: summary: Returns a list of events description: Returns a list of events. Use the ID provided from the event to create integration actions operationId: ListEvents parameters: - in: query name: event_type_in schema: type: string required: false description: Filter to return events of a specified event type - in: query name: was_dispatched schema: type: string required: false description: Filter to return only events that have associated dispatch records tags: - Events responses: 200: description: Successful response content: application/json: schema: type: array items: $ref: '#/components/schemas/Event' /managed_integrations/public/{managed_integration_uuid}/poll: get: summary: Returns a list of new events description: Returns a list of events that have not yet been dispatched for the managed integration. operationId: PollEvents parameters: - in: path name: managed_integration_uuid schema: type: string required: true description: The unique identifier for the managed integration whose events you want to poll - in: query name: create_dispatch_records schema: type: string required: false description: Whether you would like to create associated dispatch records for all events returned for this page. If set to true (or left unspecified), the events returned will not show up in the next response from this endpoint. - in: query name: event_type_in schema: type: string required: false description: Filter to return events of a specified event type - in: query name: was_dispatched schema: type: string required: false description: Filter to return only events that have associated dispatch records tags: - Events responses: 200: description: Successful response content: application/json: schema: type: array items: $ref: '#/components/schemas/Event' components: schemas: Event: type: object properties: uuid: type: string format: uuid type: type: string example: integration_action.requested description: The event type data: type: object description: Data relevant to the event related_object: type: - string - 'null' format: uuid related_object_type: type: string created: type: string readOnly: true example: '2020-08-25T18:00:53+00:00' securitySchemes: app_id: type: apiKey description: API key to authorize requests. name: Authorization in: header