Skip to main content

​
New Documents

The fastest way to upload data to Invopop is by creating an entry with the data property containing the GOBL JSON of either a pre-built Envelope or a partial document like an Invoice or Party. The key property can be used to ensure idempotency, preventing the creation of duplicate entries with the same key within the workspace. A 409 Conflict response will be provided if either the entry ID or key have been used in an existing document.
Invoice Body Example
{
  "data": {
    "$schema": "https://gobl.org/draft-0/bill/invoice",
    "series": "DEMO",
    "code": "001",
    "currency": "USD",
    "supplier": {
      "name": "Provide One Inc.",
      "tax_id": {
        "country": "US"
      },
      "addresses": [
        {
          "num": "16",
          "street": "Jessie Street",
          "locality": "San Francisco",
          "region": "CA",
          "code": "94105",
          "country": "US"
        }
      ],
      "emails": [
        {
          "addr": "billing@provideone.com"
        }
      ]
    },
    "customer": {
      "name": "Sample Consumer",
      "emails": [
        {
          "addr": "email@sample.com"
        }
      ]
    },
    "lines": [
      {
        "quantity": "20",
        "item": {
          "name": "Development services",
          "price": "90.00",
          "unit": "h"
        },
        "discounts": [
          {
            "percent": "10%",
            "reason": "Special discount"
          }
        ],
        "taxes": [
          {
            "cat": "ST",
            "percent": "8.5%"
          }
        ]
      }
    ]
  }
}
Any data uploaded to the Invopop Silo will first be normalized, calculated, and then validated to check for any errors. Invopop will attempt to automatically determine the folder in which to store the document based on the schema, but you can override this by including the folder field in the request. If there are any validation issues with the uploaded data, the service will respond with an error message including a key and message. Additionally, the fields property may include a nested structure to help identify the specific property with a validation fault.
Use UUID versions 1 or 7 for documents with a specific lifespan, such as invoices or payment receipts. For long-lived data, like parties or items, use versions 3, 4, or 5. The rules for UUID versions are enforced by specific folder configurations.

​
Creating Entries from Previous Documents

You can create new entries based on a previous entry by using the previous_id field. This allows you to provide patch data instead of a full new document by setting the patch type in the content_type field to one of the following:
  • application/json-patch+json - for JSON Patch (RFC 6902)
  • application/merge-patch+json - for JSON Merge Patch (RFC 7396)
Additionally, the previous_id field can be used to create corrective documents by including corrective option data in the correct field. For more details, refer to the GOBL documentation on correction options.