config that your organization stores under a name, for one endpoint. Send its config_id in place of config, and the request runs with the saved options. Use saved configs when many requests share the same options, or to change those options in one place without changing your code.
Save a config and use it
This example saves an Extract config for invoices, then extracts a parsed invoice with the saved config’sconfig_id:
config or config_id, never both.
Where configs are saved
Each endpoint that takes aconfig keeps its own saved configs under /{endpoint}/configs, or client.<endpoint>.configs in the SDKs: Parse, Extract, Split, Tables, Charts, Classify and Pipeline. A batch takes a /parse config. A pipeline’s steps take their configs inline, so to reuse a pipeline, save the whole pipeline under /pipeline/configs.
Manage your configs
Each endpoint’s configs have the same six routes, which the SDKs callcreate, list (newest first), get, update, delete and delete_all (deleteAll in TypeScript). delete_all deletes every config of the endpoint. In TypeScript, a call on one config takes its id as configId.
Change a saved config
PATCH takes a new name, a new config, or both. A new config replaces the saved one whole, so send every option you want to keep. This request adds a field to the invoice config:
Rules
- A saved config is checked by the same rules as the endpoint’s own
config. An invalid one is refused with a400when you save it. - A request that sends a
config_idsaved for another endpoint, a deleted one, or another organization’s is refused with a400. - Saved configs belong to your organization. Every API key in it can use, change and delete them.
- Deleting a config doesn’t change the jobs that already used it.
Next steps
Classify
Choose a saved config for each kind of document.
Config API reference
Every config route, for each endpoint.