Paperless Parts Events API

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 <api_token>"`, where `<api_token>` 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 <api_token>"`, where `<api_token>` 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