Metadata
Learn how to store arbitrary custom metadata in various objects in Monite.
Payables, Receivables, Entity, Counterpart, and Counterpart bank account objects can have arbitrary metadata associated with them. Monite API Partners can use metadata to store additional structured information about these objects, such as the object IDs from other systems. Receivables’ metadata can also be used in emails.
The way to work with metadata varies depending on the object type. Refer to the corresponding section below:
The metadata is not part of the Entity and Counterpart objects themselves. Instead, it is accessed via the /partner_metadata subresource of the corresponding resources:
Use the HTTP PUT method to set the metadata, and GET to read it.
The <resource>/partner_metadata endpoint accepts and returns the metadata in the following format, where metadata can be an arbitrary JSON object up to 2000 bytes in size:
Use PUT <resource>/partner_metadata to add metadata or replace existing metadata for a specific entity or counterpart. For example:
A 200 OK response means the metadata was successfully saved. If the metadata exceeds the 2 KB limit, a 422 response is returned.
Use GET <resource>/partner_metadata to get existing metadata for a specific entity or counterpart. For example:
If there is no metadata associated with the specified entity or counterpart, the metadata field in the response is an empty object {}.
If you need to add, modify, or delete individual fields within a metadata object, you can use this approach:
GET <resource>/partner_metadata to read existing metadata.PUT <resource>/partner_metadata to save the modified metadata.To delete the metadata associated with a specific entity or counterpart, you can call PUT <resource>/partner_metadata and pass an empty object {} as the metadata value:
Payable, Receivable, and Counterpart Bank Account objects have the partner_metadata field to store partner-provided metadata. The value can be an arbitrary JSON object up to 2000 bytes in size:
If there is no metadata associated with a specific payable, receivable, or bank account, the partner_metadata field returns an empty object—{}.
When creating a payable, receivable, or counterpart bank account, you can provide the metadata by using the partner_metadata field directly in the request object as shown:
In case of already existing payables, receivables, or counterpart bank accounts, you can add metadata by sending a PATCH request to the respective endpoint and including the partner_metadata field as shown:
To retrieve the metadata of a payable, receivable, or counterpart bank account, send a GET request to the corresponding resource.
The following snippet demonstrates a response from the GET /payables request, which includes the partner_metadata of each payable:
To add, modify, or delete individual fields within the metadata of a Payable, Receivable, or Counterpart Bank Account object, you can use this approach:
GET request (such as GET /payables/{payable_id}).partner_metadata response field to get existing metadata.partner_metadata value as needed.PATCH request to update the object and provide the updated partner_metadata value in the request.To delete existing metadata from a Payable, Receivable or Counterpart Bank Account object, send a PATCH request to the corresponding endpoint and set partner_metadata to an empty object {} as shown:
This feature is supported only for receivables: invoices, quotes, and credit notes.
Most keys defined in a receivable’s partner_metadata are automatically exposed as variables for use in emails and email templates.
These variable names are in the format
where <key> is the name of a field inside partner_metadata.
Only top-level metadata keys with primitive values (strings, numbers, booleans) are exposed as email template variables. Nested keys and keys with array or object values are not exposed as variables.
Since metadata keys can vary per receivable, the {{partner_metadata.<key>}} variables are evaluated at the moment when emails are composed to be sent.
Variable names that refer to non-existing metadata keys do not raise errors but evaluate to an empty string.
Consider an invoice with the following metadata:
You can use the following additional variables in email templates:
{{partner_metadata.dashboard_link}}{{partner_metadata.reference}}{{partner_metadata.priority}}{{partner_metadata.is_vip}}The extra and labels metadata keys are not exposed as variables because they are not primitives.
The following example includes {{partner_metadata.dashboard_link}} in the email body contents: