# Batch create annotations
Source: https://docs.affinda.com/api-reference/annotations/batch-create-annotations
https://api.affinda.com/static/v3/api_spec.yaml post /v3/annotations/batch_create
Batch create annotations
# Batch delete annotations
Source: https://docs.affinda.com/api-reference/annotations/batch-delete-annotations
https://api.affinda.com/static/v3/api_spec.yaml post /v3/annotations/batch_delete
Batch delete annotations
# Batch update annotations
Source: https://docs.affinda.com/api-reference/annotations/batch-update-annotations
https://api.affinda.com/static/v3/api_spec.yaml post /v3/annotations/batch_update
Batch update annotations
# Create a annotation
Source: https://docs.affinda.com/api-reference/annotations/create-a-annotation
https://api.affinda.com/static/v3/api_spec.yaml post /v3/annotations
Create a annotation
# Delete an annotation
Source: https://docs.affinda.com/api-reference/annotations/delete-an-annotation
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/annotations/{id}
Deletes the specified annotation from the database.
# Get list of all annotations
Source: https://docs.affinda.com/api-reference/annotations/get-list-of-all-annotations
https://api.affinda.com/static/v3/api_spec.yaml get /v3/annotations
Returns your annotations.
# Get specific annotation
Source: https://docs.affinda.com/api-reference/annotations/get-specific-annotation
https://api.affinda.com/static/v3/api_spec.yaml get /v3/annotations/{id}
Return a specific annotation.
# Update an annotation
Source: https://docs.affinda.com/api-reference/annotations/update-an-annotation
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/annotations/{id}
Update data of an annotation.
# Add value for a data source
Source: https://docs.affinda.com/api-reference/data-sources/add-value-for-a-data-source
https://api.affinda.com/static/v3/api_spec.yaml post /v3/mapping_data_sources/{identifier}/values
Adds a value to a mapping data source
# Create a data source
Source: https://docs.affinda.com/api-reference/data-sources/create-a-data-source
https://api.affinda.com/static/v3/api_spec.yaml post /v3/mapping_data_sources
Create a custom mapping data source.
# Delete specific data source
Source: https://docs.affinda.com/api-reference/data-sources/delete-specific-data-source
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/mapping_data_sources/{identifier}
Delete the specified mapping data source from the database.
# Delete specific data source value
Source: https://docs.affinda.com/api-reference/data-sources/delete-specific-data-source-value
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/mapping_data_sources/{identifier}/values/{value}
Delete the specified mapping data source value from the database.
# Get specific data source
Source: https://docs.affinda.com/api-reference/data-sources/get-specific-data-source
https://api.affinda.com/static/v3/api_spec.yaml get /v3/mapping_data_sources/{identifier}
Return a specific mapping data source.
# Get specific data source value
Source: https://docs.affinda.com/api-reference/data-sources/get-specific-data-source-value
https://api.affinda.com/static/v3/api_spec.yaml get /v3/mapping_data_sources/{identifier}/values/{value}
Return a specific mapping dta source value.
# List data sources
Source: https://docs.affinda.com/api-reference/data-sources/list-data-sources
https://api.affinda.com/static/v3/api_spec.yaml get /v3/mapping_data_sources
Returns the list of all custom mapping data sources.
# List values for a data source
Source: https://docs.affinda.com/api-reference/data-sources/list-values-for-a-data-source
https://api.affinda.com/static/v3/api_spec.yaml get /v3/mapping_data_sources/{identifier}/values
Returns the list of all values in a mapping data source
# Replace values for a data source
Source: https://docs.affinda.com/api-reference/data-sources/replace-values-for-a-data-source
https://api.affinda.com/static/v3/api_spec.yaml put /v3/mapping_data_sources/{identifier}/values
Replaces the list of all values in a mapping data source
Note: For large data sources (e.g. > 1000 values), it can take a few minutes after the request completes for the new values to be searchable.
# Update specific data source value
Source: https://docs.affinda.com/api-reference/data-sources/update-specific-data-source-value
https://api.affinda.com/static/v3/api_spec.yaml put /v3/mapping_data_sources/{identifier}/values/{value}
Update the specified mapping data source value.
# Create a collection
Source: https://docs.affinda.com/api-reference/deprecated-end-points/create-a-collection
https://api.affinda.com/static/v3/api_spec.yaml post /v3/collections
Create a collection
# Create a data point
Source: https://docs.affinda.com/api-reference/deprecated-end-points/create-a-data-point
https://api.affinda.com/static/v3/api_spec.yaml post /v3/data_points
Create a custom data point.
# Create a data point choice
Source: https://docs.affinda.com/api-reference/deprecated-end-points/create-a-data-point-choice
https://api.affinda.com/static/v3/api_spec.yaml post /v3/data_point_choices
Create a custom data point choice.
# Create a mapping
Source: https://docs.affinda.com/api-reference/deprecated-end-points/create-a-mapping
https://api.affinda.com/static/v3/api_spec.yaml post /v3/mappings
Create a custom mapping.
# Create data field for a collection along with a new data point.
Source: https://docs.affinda.com/api-reference/deprecated-end-points/create-data-field-for-a-collection-along-with-a-new-data-point
https://api.affinda.com/static/v3/api_spec.yaml post /v3/collections/{identifier}/create_data_field
Create data field for a collection along with a new data point.
# Delete a collection
Source: https://docs.affinda.com/api-reference/deprecated-end-points/delete-a-collection
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/collections/{identifier}
Deletes the specified collection from the database.
# Delete a data point
Source: https://docs.affinda.com/api-reference/deprecated-end-points/delete-a-data-point
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/data_points/{identifier}
Deletes the specified data point from the database.
# Delete a data point choice
Source: https://docs.affinda.com/api-reference/deprecated-end-points/delete-a-data-point-choice
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/data_point_choices/{id}
Deletes the specified data point choice from the database.
# Delete specific mapping
Source: https://docs.affinda.com/api-reference/deprecated-end-points/delete-specific-mapping
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/mappings/{identifier}
Delete the specified mapping from the database.
# Get data field for a collection assosciated with a data point.
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-data-field-for-a-collection-assosciated-with-a-data-point
https://api.affinda.com/static/v3/api_spec.yaml get /v3/collections/{identifier}/fields/{datapoint_identifier}
Get a data field for a collection assosciated with a data point
# Get list of all collections
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-list-of-all-collections
https://api.affinda.com/static/v3/api_spec.yaml get /v3/collections
Returns your collections.
# Get list of all data points
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-list-of-all-data-points
https://api.affinda.com/static/v3/api_spec.yaml get /v3/data_points
Returns your custom data points as well as Affinda's off-the-shelf data points.
# Get list of data point choices
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-list-of-data-point-choices
https://api.affinda.com/static/v3/api_spec.yaml get /v3/data_point_choices
Returns available choices for a specific enum data point.
# Get specific collection
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-specific-collection
https://api.affinda.com/static/v3/api_spec.yaml get /v3/collections/{identifier}
Return a specific collection.
# Get specific data point
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-specific-data-point
https://api.affinda.com/static/v3/api_spec.yaml get /v3/data_points/{identifier}
Return a specific data point.
# Get specific data point choice
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-specific-data-point-choice
https://api.affinda.com/static/v3/api_spec.yaml get /v3/data_point_choices/{id}
Return a specific data point choice.
# Get specific mapping
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-specific-mapping
https://api.affinda.com/static/v3/api_spec.yaml get /v3/mappings/{identifier}
Return a specific mapping.
# Get usage by collection
Source: https://docs.affinda.com/api-reference/deprecated-end-points/get-usage-by-collection
https://api.affinda.com/static/v3/api_spec.yaml get /v3/collections/{identifier}/usage
Return monthly credits consumption of a collection.
Deprecated: use `GET /v3/usage?organization={id}&document_type={id}` instead. The new endpoint returns a unified daily series and uses the modern "document type" terminology.
# List mappings
Source: https://docs.affinda.com/api-reference/deprecated-end-points/list-mappings
https://api.affinda.com/static/v3/api_spec.yaml get /v3/mappings
Returns the list of all custom data mappings.
# Replace choices of a data point
Source: https://docs.affinda.com/api-reference/deprecated-end-points/replace-choices-of-a-data-point
https://api.affinda.com/static/v3/api_spec.yaml post /v3/data_point_choices/replace
Replace choices of a data point. Existing choices and incoming choices are matched base on their `value`. New `value` will be created, existing `value` will be updated, and `value` not in incoming choices will be deleted.
# Update a collection
Source: https://docs.affinda.com/api-reference/deprecated-end-points/update-a-collection
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/collections/{identifier}
Update data of a collection.
# Update a data point
Source: https://docs.affinda.com/api-reference/deprecated-end-points/update-a-data-point
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/data_points/{identifier}
Update data of a data point.
# Update a data point choice
Source: https://docs.affinda.com/api-reference/deprecated-end-points/update-a-data-point-choice
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/data_point_choices/{id}
Update data of a data point choice.
# Update data field for a collection assosciated with a data point.
Source: https://docs.affinda.com/api-reference/deprecated-end-points/update-data-field-for-a-collection-assosciated-with-a-data-point
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/collections/{identifier}/fields/{datapoint_identifier}
Update data field for a collection assosciated with a data point
# Update specific mapping
Source: https://docs.affinda.com/api-reference/deprecated-end-points/update-specific-mapping
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/mappings/{identifier}
Updates a specific mapping.
# Create a document type
Source: https://docs.affinda.com/api-reference/document-types/create-a-document-type
https://api.affinda.com/static/v3/api_spec.yaml post /v3/document_types
Create a new document type in the specified organization.
# Delete a document type
Source: https://docs.affinda.com/api-reference/document-types/delete-a-document-type
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/document_types/{identifier}
Delete a document type.
# Generate JSON schema from a document type
Source: https://docs.affinda.com/api-reference/document-types/generate-json-schema-from-a-document-type
https://api.affinda.com/static/v3/api_spec.yaml get /v3/document_types/{identifier}/json_schema
Generate JSON schema from a document type.
# Generate Pydantic models from a document type
Source: https://docs.affinda.com/api-reference/document-types/generate-pydantic-models-from-a-document-type
https://api.affinda.com/static/v3/api_spec.yaml get /v3/document_types/{identifier}/pydantic_models
Generate Pydantic models from a document type.
# Get a document type
Source: https://docs.affinda.com/api-reference/document-types/get-a-document-type
https://api.affinda.com/static/v3/api_spec.yaml get /v3/document_types/{identifier}
Returns the details of a specific document type.
# List document types
Source: https://docs.affinda.com/api-reference/document-types/list-document-types
https://api.affinda.com/static/v3/api_spec.yaml get /v3/document_types
Returns a list of document types that the user has access to.
# Update a document type
Source: https://docs.affinda.com/api-reference/document-types/update-a-document-type
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/document_types/{identifier}
Update an existing document type.
# Delete a document
Source: https://docs.affinda.com/api-reference/documents/delete-a-document
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/documents/{identifier}
Deletes the specified document from the database.
# Get list of all documents
Source: https://docs.affinda.com/api-reference/documents/get-list-of-all-documents
https://api.affinda.com/static/v3/api_spec.yaml get /v3/documents
Returns all the document summaries for that user, limited to 300 per page.
# Get redacted document
Source: https://docs.affinda.com/api-reference/documents/get-redacted-document
https://api.affinda.com/static/v3/api_spec.yaml get /v3/documents/{identifier}/redacted
Get the redacted version of a document. The original document is not modified.
# Get specific document
Source: https://docs.affinda.com/api-reference/documents/get-specific-document
https://api.affinda.com/static/v3/api_spec.yaml get /v3/documents/{identifier}
Return a specific document.
# Update a document
Source: https://docs.affinda.com/api-reference/documents/update-a-document
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/documents/{identifier}
Update file name, expiry time, or move to another collection, etc.
# Upload a document for parsing
Source: https://docs.affinda.com/api-reference/documents/upload-a-document-for-parsing
https://api.affinda.com/static/v3/api_spec.yaml post /v3/documents
Uploads a document for parsing via file upload or URL.
When successful, returns an `identifier` in the response for subsequent use with the [/documents/{identifier}](#get-/v3/documents/-identifier-) endpoint to check processing status and retrieve results.
# Delete an invoice
Source: https://docs.affinda.com/api-reference/invoice-extractor/delete-an-invoice
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/invoices/{identifier}
Delete the specified invoice from the database. Note, any invoices deleted from the database will no longer be used in any tailored customer models.
# Get list of all invoices
Source: https://docs.affinda.com/api-reference/invoice-extractor/get-list-of-all-invoices
https://api.affinda.com/static/v2/api_spec.yaml get /v2/invoices
Returns all the invoice summaries for that user, limited to 300 per page.
# Get parse results for a specific invoice
Source: https://docs.affinda.com/api-reference/invoice-extractor/get-parse-results-for-a-specific-invoice
https://api.affinda.com/static/v2/api_spec.yaml get /v2/invoices/{identifier}
Returns all the parse results for that invoice if processing is completed.
The `identifier` is the unique ID returned after POST-ing the invoice via the [/invoices](#post-/invoices) endpoint.
# Upload an invoice for parsing
Source: https://docs.affinda.com/api-reference/invoice-extractor/upload-an-invoice-for-parsing
https://api.affinda.com/static/v2/api_spec.yaml post /v2/invoices
Uploads an invoice for parsing.
When successful, returns an `identifier` in the response for subsequent use with the [/invoices/{identifier}](#get-/invoices/-identifier-) endpoint to check processing status and retrieve results.
# Delete a job description
Source: https://docs.affinda.com/api-reference/job-description-parser/delete-a-job-description
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/job_descriptions/{identifier}
Deletes the specified job description from the database
# Get job description results for a specific job description file
Source: https://docs.affinda.com/api-reference/job-description-parser/get-job-description-results-for-a-specific-job-description-file
https://api.affinda.com/static/v2/api_spec.yaml get /v2/job_descriptions/{identifier}
Returns all the results for that job description if processing is completed.
The `identifier` is the unique ID returned after POST-ing the resume via the [/job_descriptions](#post-/job_descriptions) endpoint.
# Get list of all job descriptions
Source: https://docs.affinda.com/api-reference/job-description-parser/get-list-of-all-job-descriptions
https://api.affinda.com/static/v2/api_spec.yaml get /v2/job_descriptions
Returns all the job descriptions for that user, limited to 300 per page.
# Update a job description's data
Source: https://docs.affinda.com/api-reference/job-description-parser/update-a-job-descriptions-data
https://api.affinda.com/static/v2/api_spec.yaml patch /v2/job_descriptions/{identifier}
Update data of a job description.
The `identifier` is the unique ID returned after POST-ing the job description via the [/job_descriptions](#post-/job_descriptions) endpoint.
# Upload a job description for parsing
Source: https://docs.affinda.com/api-reference/job-description-parser/upload-a-job-description-for-parsing
https://api.affinda.com/static/v2/api_spec.yaml post /v2/job_descriptions
Uploads a job description for parsing.
When successful, returns an `identifier` in the response for subsequent use with the [/job_descriptions/{identifier}](#get-/job_descriptions/-identifier-) endpoint to check processing status and retrieve results.
Job Descriptions can be uploaded as a file or a URL. In addition, data can be added directly if users want to upload directly without parsing any resume file. For uploading resume data, the `data` argument provided must be a JSON-encoded string. Data uploads will not impact upon parsing credits.
# Get detail of an organization
Source: https://docs.affinda.com/api-reference/organizations/get-detail-of-an-organization
https://api.affinda.com/static/v3/api_spec.yaml get /v3/organizations/{identifier}
Get detail of an organization.
# Get list of all organizations
Source: https://docs.affinda.com/api-reference/organizations/get-list-of-all-organizations
https://api.affinda.com/static/v3/api_spec.yaml get /v3/organizations
Returns all the organizations
# Delete a resume
Source: https://docs.affinda.com/api-reference/resume-parser/delete-a-resume
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/resumes/{identifier}
Deletes the specified resume from the database
# Get list of all resumes
Source: https://docs.affinda.com/api-reference/resume-parser/get-list-of-all-resumes
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resumes
Returns all the resume summaries for that user, limited to 300 per page.
# Get parse results for a specific resume
Source: https://docs.affinda.com/api-reference/resume-parser/get-parse-results-for-a-specific-resume
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resumes/{identifier}
Returns all the parse results for that resume if processing is completed.
The `identifier` is the unique ID returned after POST-ing the resume via the [/resumes](#post-/resumes) endpoint.
# Update a resume's data
Source: https://docs.affinda.com/api-reference/resume-parser/update-a-resumes-data
https://api.affinda.com/static/v2/api_spec.yaml patch /v2/resumes/{identifier}
Update data of a parsed resume.
The `identifier` is the unique ID returned after POST-ing the resume via the [/resumes](#post-/resumes) endpoint.
# Upload a resume for parsing
Source: https://docs.affinda.com/api-reference/resume-parser/upload-a-resume-for-parsing
https://api.affinda.com/static/v2/api_spec.yaml post /v2/resumes
**New customers:** this endpoint is part of our legacy v2 API. We recommend using the [POST /documents](#post-/documents) endpoint from our updated API instead — it supports parsing of all document types (resumes, invoices, etc.) through a single, unified interface.
Uploads a resume for parsing. When successful, returns an `identifier` in the response for subsequent use with the [/resumes/{identifier}](#get-/resumes/-identifier-) endpoint to check processing status and retrieve results.
Resumes can be uploaded as a file or a URL. In addition, data can be added directly if users want to upload directly without parsing any resume file. For uploading resume data, the `data` argument provided must be a JSON-encoded string. Data uploads will not impact upon parsing credits.
# Delete a redacted resume
Source: https://docs.affinda.com/api-reference/resume-redactor/delete-a-redacted-resume
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/redacted_resumes/{identifier}
Deletes the specified resume from the database
# Get list of all redacted resumes
Source: https://docs.affinda.com/api-reference/resume-redactor/get-list-of-all-redacted-resumes
https://api.affinda.com/static/v2/api_spec.yaml get /v2/redacted_resumes
Returns all the redacted resume information for that resume
# Get redaction results for a specific resume
Source: https://docs.affinda.com/api-reference/resume-redactor/get-redaction-results-for-a-specific-resume
https://api.affinda.com/static/v2/api_spec.yaml get /v2/redacted_resumes/{identifier}
Returns all the redaction results for that resume if processing is completed.
The `identifier` is the unique ID returned after POST-ing the resume via the [/redacted_resumes](#post-/redacted_resumes) endpoint.
# Upload a resume for redacting
Source: https://docs.affinda.com/api-reference/resume-redactor/upload-a-resume-for-redacting
https://api.affinda.com/static/v2/api_spec.yaml post /v2/redacted_resumes
Uploads a resume for redacting.
# Create a signed URL for the embeddable job description search tool
Source: https://docs.affinda.com/api-reference/search-&-match--embedding/create-a-signed-url-for-the-embeddable-job-description-search-tool
https://api.affinda.com/static/v2/api_spec.yaml post /v2/job_description_search/embed
Create and return a signed URL of the job description search tool which then can be embedded on a web page. An optional parameter `config_override` can be passed to override the user-level configurations of the embeddable search tool.
# Create a signed URL for the embeddable resume search tool
Source: https://docs.affinda.com/api-reference/search-&-match--embedding/create-a-signed-url-for-the-embeddable-resume-search-tool
https://api.affinda.com/static/v2/api_spec.yaml post /v2/resume_search/embed
Create and return a signed URL of the resume search tool which then can be embedded on a web page. An optional parameter `config_override` can be passed to override the user-level configurations of the embeddable resume search tool.
# Get the config for the logged in user's embeddable job description search tool
Source: https://docs.affinda.com/api-reference/search-&-match--embedding/get-the-config-for-the-logged-in-users-embeddable-job-description-search-tool
https://api.affinda.com/static/v2/api_spec.yaml get /v2/job_description_search/config
Return configurations such as which fields can be displayed in the logged in user's embeddable job description search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Get the config for the logged in user's embeddable resume search tool
Source: https://docs.affinda.com/api-reference/search-&-match--embedding/get-the-config-for-the-logged-in-users-embeddable-resume-search-tool
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resume_search/config
Return configurations such as which fields can be displayed in the logged in user's embeddable resume search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Update the config for the logged in user's embeddable job description search tool
Source: https://docs.affinda.com/api-reference/search-&-match--embedding/update-the-config-for-the-logged-in-users-embeddable-job-description-search-tool
https://api.affinda.com/static/v2/api_spec.yaml patch /v2/job_description_search/config
Update configurations such as which fields can be displayed in the logged in user's embeddable job description search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Update the config for the logged in user's embeddable resume search tool
Source: https://docs.affinda.com/api-reference/search-&-match--embedding/update-the-config-for-the-logged-in-users-embeddable-resume-search-tool
https://api.affinda.com/static/v2/api_spec.yaml patch /v2/resume_search/config
Update configurations such as which fields can be displayed in the logged in user's embeddable resume search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Create a new index
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/create-a-new-index
https://api.affinda.com/static/v2/api_spec.yaml post /v2/index
Create an index for the search tool
# Delete an index
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/delete-an-index
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/index/{name}
Deletes the specified index from the database
# Delete an indexed document
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/delete-an-indexed-document
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/index/{name}/documents/{identifier}
Delete the specified indexed document from the database
# Get indexed documents for a specific index
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/get-indexed-documents-for-a-specific-index
https://api.affinda.com/static/v2/api_spec.yaml get /v2/index/{name}/documents
Returns all the indexed documents for that index
# Get list of all indexes
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/get-list-of-all-indexes
https://api.affinda.com/static/v2/api_spec.yaml get /v2/index
Returns all the indexes
# Index a new document
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/index-a-new-document
https://api.affinda.com/static/v2/api_spec.yaml post /v2/index/{name}/documents
Create an indexed document for the search tool
# Update an index
Source: https://docs.affinda.com/api-reference/search-&-match--indexing/update-an-index
https://api.affinda.com/static/v2/api_spec.yaml patch /v2/index/{name}
Updates the specified index
# Get job title suggestions based on provided job title(s)
Source: https://docs.affinda.com/api-reference/search-&-match--searching/get-job-title-suggestions-based-on-provided-job-titles
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resume_search/suggestion_job_title
Provided one or more job titles, get related suggestions for your search.
# Get search result of specific job description
Source: https://docs.affinda.com/api-reference/search-&-match--searching/get-search-result-of-specific-job-description
https://api.affinda.com/static/v2/api_spec.yaml post /v2/job_description_search/details/{identifier}
This contains more detailed information about the matching score of the search criteria, or which search criteria is missing in this job description.
The `identifier` is the unique ID returned via the [/job_description_search](#post-/job_description_search) endpoint.
# Get search result of specific resume
Source: https://docs.affinda.com/api-reference/search-&-match--searching/get-search-result-of-specific-resume
https://api.affinda.com/static/v2/api_spec.yaml post /v2/resume_search/details/{identifier}
This contains more detailed information about the matching score of the search criteria, or which search criteria is missing in this resume.
The `identifier` is the unique ID returned via the [/resume_search](#post-/resume_search) endpoint.
# Get skill suggestions based on provided skill(s)
Source: https://docs.affinda.com/api-reference/search-&-match--searching/get-skill-suggestions-based-on-provided-skills
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resume_search/suggestion_skill
Provided one or more skills, get related suggestions for your search.
# List occupation groups
Source: https://docs.affinda.com/api-reference/search-&-match--searching/list-occupation-groups
https://api.affinda.com/static/v2/api_spec.yaml get /v2/occupation_groups
Returns the list of searchable occupation groups.
# Match a single resume and job description
Source: https://docs.affinda.com/api-reference/search-&-match--searching/match-a-single-resume-and-job-description
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resume_search/match
Get the matching score between a resume and a job description. The score ranges between 0 and 1, with 0 being not a match at all, and 1 being perfect match.
Note, this score will not directly match the score returned from POST [/resume_search/details/{identifier}](#post-/resume_search/details/-identifier-).
# Search through parsed job descriptions
Source: https://docs.affinda.com/api-reference/search-&-match--searching/search-through-parsed-job-descriptions
https://api.affinda.com/static/v2/api_spec.yaml post /v2/job_description_search
Searches through parsed job descriptions. You can search with custom criterias or a resume.
# Search through parsed resumes
Source: https://docs.affinda.com/api-reference/search-&-match--searching/search-through-parsed-resumes
https://api.affinda.com/static/v2/api_spec.yaml post /v2/resume_search
Searches through parsed resumes. Users have 3 options to create a search:
1. Match to a job description - a parsed job description is used to find candidates that suit it
2. Match to a resume - a parsed resume is used to find other candidates that have similar attributes
3. Search using custom criteria
Users should only populate 1 of jobDescription, resume or the custom criteria.
# Create a document from raw data
Source: https://docs.affinda.com/api-reference/search-&-match/create-a-document-from-raw-data
https://api.affinda.com/static/v3/api_spec.yaml post /v3/documents/create_from_data
Creates a document directly from structured resume or job description data for use in Search & Match functionality. This endpoint is specifically designed for programmatic document creation without file uploads.
If you want to upload a document with a file or URL, see the main [POST /v3/documents](#post-/v3/documents) endpoint under the Documents tag.
When successful, returns an `identifier` in the response for subsequent use with the [/documents/{identifier}](#get-/v3/documents/-identifier-) endpoint to check processing status and retrieve results.
# Create a new index
Source: https://docs.affinda.com/api-reference/search-&-match/create-a-new-index
https://api.affinda.com/static/v3/api_spec.yaml post /v3/index
Create an index for the search tool
# Create a signed URL for the embeddable job description search tool
Source: https://docs.affinda.com/api-reference/search-&-match/create-a-signed-url-for-the-embeddable-job-description-search-tool
https://api.affinda.com/static/v3/api_spec.yaml post /v3/job_description_search/embed
Create and return a signed URL of the job description search tool which then can be embedded on a web page. An optional parameter `config_override` can be passed to override the user-level configurations of the embeddable search tool.
# Create a signed URL for the embeddable resume search tool
Source: https://docs.affinda.com/api-reference/search-&-match/create-a-signed-url-for-the-embeddable-resume-search-tool
https://api.affinda.com/static/v3/api_spec.yaml post /v3/resume_search/embed
Create and return a signed URL of the resume search tool which then can be embedded on a web page. An optional parameter `config_override` can be passed to override the user-level configurations of the embeddable resume search tool.
# Delete an index
Source: https://docs.affinda.com/api-reference/search-&-match/delete-an-index
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/index/{name}
Deletes the specified index from the database
# Delete an indexed document
Source: https://docs.affinda.com/api-reference/search-&-match/delete-an-indexed-document
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/index/{name}/documents/{identifier}
Delete the specified indexed document from the database
# Get indexed documents for a specific index
Source: https://docs.affinda.com/api-reference/search-&-match/get-indexed-documents-for-a-specific-index
https://api.affinda.com/static/v3/api_spec.yaml get /v3/index/{name}/documents
Returns all the indexed documents for that index
# Get job title suggestions based on provided job title(s)
Source: https://docs.affinda.com/api-reference/search-&-match/get-job-title-suggestions-based-on-provided-job-titles
https://api.affinda.com/static/v3/api_spec.yaml get /v3/resume_search/suggestion_job_title
Provided one or more job titles, get related suggestions for your search.
# Get list of all indexes
Source: https://docs.affinda.com/api-reference/search-&-match/get-list-of-all-indexes
https://api.affinda.com/static/v3/api_spec.yaml get /v3/index
Returns all the indexes
# Get search result of specific job description
Source: https://docs.affinda.com/api-reference/search-&-match/get-search-result-of-specific-job-description
https://api.affinda.com/static/v3/api_spec.yaml post /v3/job_description_search/details/{identifier}
This contains more detailed information about the matching score of the search criteria, or which search criteria is missing in this job description.
The `identifier` is the unique ID returned via the [/job_description_search](#post-/job_description_search) endpoint.
# Get search result of specific resume
Source: https://docs.affinda.com/api-reference/search-&-match/get-search-result-of-specific-resume
https://api.affinda.com/static/v3/api_spec.yaml post /v3/resume_search/details/{identifier}
This contains more detailed information about the matching score of the search criteria, or which search criteria is missing in this resume.
The `identifier` is the unique ID returned via the [/resume_search](#post-/resume_search) endpoint.
# Get skill suggestions based on provided skill(s)
Source: https://docs.affinda.com/api-reference/search-&-match/get-skill-suggestions-based-on-provided-skills
https://api.affinda.com/static/v3/api_spec.yaml get /v3/resume_search/suggestion_skill
Provided one or more skills, get related suggestions for your search.
# Get the config for the logged in user's embeddable job description search tool
Source: https://docs.affinda.com/api-reference/search-&-match/get-the-config-for-the-logged-in-users-embeddable-job-description-search-tool
https://api.affinda.com/static/v3/api_spec.yaml get /v3/job_description_search/config
Return configurations such as which fields can be displayed in the logged in user's embeddable job description search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Get the config for the logged in user's embeddable resume search tool
Source: https://docs.affinda.com/api-reference/search-&-match/get-the-config-for-the-logged-in-users-embeddable-resume-search-tool
https://api.affinda.com/static/v3/api_spec.yaml get /v3/resume_search/config
Return configurations such as which fields can be displayed in the logged in user's embeddable resume search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Index a new document
Source: https://docs.affinda.com/api-reference/search-&-match/index-a-new-document
https://api.affinda.com/static/v3/api_spec.yaml post /v3/index/{name}/documents
Create an indexed document for the search tool
# List occupation groups
Source: https://docs.affinda.com/api-reference/search-&-match/list-occupation-groups
https://api.affinda.com/static/v3/api_spec.yaml get /v3/occupation_groups
Returns the list of searchable occupation groups.
# Match a single resume and job description
Source: https://docs.affinda.com/api-reference/search-&-match/match-a-single-resume-and-job-description
https://api.affinda.com/static/v3/api_spec.yaml get /v3/resume_search/match
Get the matching score between a resume and a job description. The score ranges between 0 and 1, with 0 being not a match at all, and 1 being perfect match.
Note, this score will not directly match the score returned from POST [/resume_search/details/{identifier}](#post-/resume_search/details/-identifier-).
# Re-index a document
Source: https://docs.affinda.com/api-reference/search-&-match/re-index-a-document
https://api.affinda.com/static/v3/api_spec.yaml post /v3/index/{name}/documents/{identifier}/re_index
Re-index a document.
This is relevant if you updated the document's data via the /annotations endpoint, and want to refresh
the document's data in the search index.
# Search through parsed job descriptions
Source: https://docs.affinda.com/api-reference/search-&-match/search-through-parsed-job-descriptions
https://api.affinda.com/static/v3/api_spec.yaml post /v3/job_description_search
Searches through parsed job descriptions. You can search with custom criterias or a resume.
# Search through parsed resumes
Source: https://docs.affinda.com/api-reference/search-&-match/search-through-parsed-resumes
https://api.affinda.com/static/v3/api_spec.yaml post /v3/resume_search
Searches through parsed resumes. Users have 3 options to create a search:
1. Match to a job description - a parsed job description is used to find candidates that suit it
2. Match to a resume - a parsed resume is used to find other candidates that have similar attributes
3. Search using custom criteria
Users should only populate 1 of jobDescription, resume or the custom criteria.
# Update a document's data
Source: https://docs.affinda.com/api-reference/search-&-match/update-a-documents-data
https://api.affinda.com/static/v3/api_spec.yaml post /v3/documents/{identifier}/update_data
Update data of a document.
Only applicable for resumes and job descriptions. For other document types, please use the `PATCH /annotations/{id}` endpoint or the `POST /annotations/batch_update` endpoint.
# Update an index
Source: https://docs.affinda.com/api-reference/search-&-match/update-an-index
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/index/{name}
Updates the specified index
# Update the config for the logged in user's embeddable job description search tool
Source: https://docs.affinda.com/api-reference/search-&-match/update-the-config-for-the-logged-in-users-embeddable-job-description-search-tool
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/job_description_search/config
Update configurations such as which fields can be displayed in the logged in user's embeddable job description search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Update the config for the logged in user's embeddable resume search tool
Source: https://docs.affinda.com/api-reference/search-&-match/update-the-config-for-the-logged-in-users-embeddable-resume-search-tool
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/resume_search/config
Update configurations such as which fields can be displayed in the logged in user's embeddable resume search tool, what are their weights, what is the maximum number of results that can be returned, etc.
# Add a tag to documents
Source: https://docs.affinda.com/api-reference/tags/add-a-tag-to-documents
https://api.affinda.com/static/v3/api_spec.yaml post /v3/documents/batch_add_tag
Add a tag to documents.
Tags are used to group documents together.
Tags can be used to filter documents.
# Create a tag
Source: https://docs.affinda.com/api-reference/tags/create-a-tag
https://api.affinda.com/static/v3/api_spec.yaml post /v3/tags
Create a tag
# Delete an tag
Source: https://docs.affinda.com/api-reference/tags/delete-an-tag
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/tags/{id}
Deletes the specified tag from the database.
# Get list of all tags
Source: https://docs.affinda.com/api-reference/tags/get-list-of-all-tags
https://api.affinda.com/static/v3/api_spec.yaml get /v3/tags
Returns your tags.
# Get specific tag
Source: https://docs.affinda.com/api-reference/tags/get-specific-tag
https://api.affinda.com/static/v3/api_spec.yaml get /v3/tags/{id}
Return a specific tag.
# Remove a tag from documents
Source: https://docs.affinda.com/api-reference/tags/remove-a-tag-from-documents
https://api.affinda.com/static/v3/api_spec.yaml post /v3/documents/batch_remove_tag
Remove a tag from documents.
# Update a tag
Source: https://docs.affinda.com/api-reference/tags/update-a-tag
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/tags/{id}
Update data of an tag.
# Get usage
Source: https://docs.affinda.com/api-reference/usage/get-usage
https://api.affinda.com/static/v3/api_spec.yaml get /v3/usage
Returns daily credits consumption for an organization over a date range. Optionally scope the report to a single workspace, a single document type, or a single (workspace × document type) pair by supplying both `workspace` and `document_type`.
# Batch create validation results
Source: https://docs.affinda.com/api-reference/validation-results/batch-create-validation-results
https://api.affinda.com/static/v3/api_spec.yaml post /v3/validation_results/batch_create
Batch create validation results.
# Batch delete validation results
Source: https://docs.affinda.com/api-reference/validation-results/batch-delete-validation-results
https://api.affinda.com/static/v3/api_spec.yaml post /v3/validation_results/batch_delete
Batch delete validation results
# Create a validation result
Source: https://docs.affinda.com/api-reference/validation-results/create-a-validation-result
https://api.affinda.com/static/v3/api_spec.yaml post /v3/validation_results
Create a validation result.
# Delete a validation result
Source: https://docs.affinda.com/api-reference/validation-results/delete-a-validation-result
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/validation_results/{id}
Remove validation result.
# Get list of all validation results
Source: https://docs.affinda.com/api-reference/validation-results/get-list-of-all-validation-results
https://api.affinda.com/static/v3/api_spec.yaml get /v3/validation_results
Returns the validation results of a document.
# Get specific validation result
Source: https://docs.affinda.com/api-reference/validation-results/get-specific-validation-result
https://api.affinda.com/static/v3/api_spec.yaml get /v3/validation_results/{id}
Return a specific validation result.
# Update a validation result
Source: https://docs.affinda.com/api-reference/validation-results/update-a-validation-result
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/validation_results/{id}
Update a validation result.
# Activate a resthook subscription
Source: https://docs.affinda.com/api-reference/webhook-api/activate-a-resthook-subscription
https://api.affinda.com/static/v2/api_spec.yaml post /v2/resthook_subscriptions/activate
After creating a subscription, we'll send a POST request to your target URL with a `X-Hook-Secret` header.
You should response to this with a 200 status code, and use the value of the `X-Hook-Secret` header that you received to activate the subscription using this endpoint.
# Create a resthook subscription
Source: https://docs.affinda.com/api-reference/webhook-api/create-a-resthook-subscription
https://api.affinda.com/static/v2/api_spec.yaml post /v2/resthook_subscriptions
After a subscription is successfully created, we'll send a POST request to your target URL with a `X-Hook-Secret` header.
You need to response to this request with a 200 status code to confirm your subscribe intention.
Then, you need to use the `X-Hook-Secret` to activate the subscription using the [/resthook_subscriptions/activate](#post-/v3/resthook_subscriptions/activate) endpoint.
For more information and detailed instructions, [see our webhooks documentation here.](https://docs.affinda.com/docs/webhooks)
# Delete a resthook subscription
Source: https://docs.affinda.com/api-reference/webhook-api/delete-a-resthook-subscription
https://api.affinda.com/static/v2/api_spec.yaml delete /v2/resthook_subscriptions/{id}
Deletes the specified resthook subscription from the database.
# Get list of all resthook subscriptions
Source: https://docs.affinda.com/api-reference/webhook-api/get-list-of-all-resthook-subscriptions
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resthook_subscriptions
Returns your resthook subscriptions.
# Get specific resthook subscription
Source: https://docs.affinda.com/api-reference/webhook-api/get-specific-resthook-subscription
https://api.affinda.com/static/v2/api_spec.yaml get /v2/resthook_subscriptions/{id}
Return a specific resthook subscription.
# Update a resthook subscription
Source: https://docs.affinda.com/api-reference/webhook-api/update-a-resthook-subscription
https://api.affinda.com/static/v2/api_spec.yaml patch /v2/resthook_subscriptions/{id}
Update data of a resthook subscription.
# Activate a resthook subscription
Source: https://docs.affinda.com/api-reference/webhooks/activate-a-resthook-subscription
https://api.affinda.com/static/v3/api_spec.yaml post /v3/resthook_subscriptions/activate
After creating a subscription, we'll send a POST request to your target URL with a `X-Hook-Secret` header.
You should response to this with a 200 status code, and use the value of the `X-Hook-Secret` header that you received to activate the subscription using this endpoint.
# Create a resthook subscription
Source: https://docs.affinda.com/api-reference/webhooks/create-a-resthook-subscription
https://api.affinda.com/static/v3/api_spec.yaml post /v3/resthook_subscriptions
After a subscription is successfully created, we'll send a POST request to your target URL with a `X-Hook-Secret` header.
You need to response to this request with a 200 status code to confirm your subscribe intention.
Then, you need to use the `X-Hook-Secret` to activate the subscription using the [/resthook_subscriptions/activate](#post-/v3/resthook_subscriptions/activate) endpoint.
For more information and detailed instructions, [see our webhooks documentation here.](https://docs.affinda.com/docs/webhooks)
# Delete a resthook subscription
Source: https://docs.affinda.com/api-reference/webhooks/delete-a-resthook-subscription
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/resthook_subscriptions/{id}
Deletes the specified resthook subscription from the database.
# Get list of all resthook subscriptions
Source: https://docs.affinda.com/api-reference/webhooks/get-list-of-all-resthook-subscriptions
https://api.affinda.com/static/v3/api_spec.yaml get /v3/resthook_subscriptions
Returns your resthook subscriptions.
# Get specific resthook subscription
Source: https://docs.affinda.com/api-reference/webhooks/get-specific-resthook-subscription
https://api.affinda.com/static/v3/api_spec.yaml get /v3/resthook_subscriptions/{id}
Return a specific resthook subscription.
# Update a resthook subscription
Source: https://docs.affinda.com/api-reference/webhooks/update-a-resthook-subscription
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/resthook_subscriptions/{id}
Update data of a resthook subscription.
# Create a workspace
Source: https://docs.affinda.com/api-reference/workspaces/create-a-workspace
https://api.affinda.com/static/v3/api_spec.yaml post /v3/workspaces
Create a workspace
# Delete a workspace
Source: https://docs.affinda.com/api-reference/workspaces/delete-a-workspace
https://api.affinda.com/static/v3/api_spec.yaml delete /v3/workspaces/{identifier}
Deletes the specified workspace from the database.
# Get list of all workspaces
Source: https://docs.affinda.com/api-reference/workspaces/get-list-of-all-workspaces
https://api.affinda.com/static/v3/api_spec.yaml get /v3/workspaces
Returns your workspaces.
# Get specific workspace
Source: https://docs.affinda.com/api-reference/workspaces/get-specific-workspace
https://api.affinda.com/static/v3/api_spec.yaml get /v3/workspaces/{identifier}
Return a specific workspace.
# Update a workspace
Source: https://docs.affinda.com/api-reference/workspaces/update-a-workspace
https://api.affinda.com/static/v3/api_spec.yaml patch /v3/workspaces/{identifier}
Update a workspace.
# Billing, credits, and payment options
Source: https://docs.affinda.com/billing
Overview of Affinda's credit-based pricing, payment methods, invoicing, and enterprise billing options for document parsing and extraction usage.
## Credits
Affinda applies usage limits through two distinct credit systems, tailored to different product categories:
* **Page Credits**
Most products use a page-based credit system, where credits are consumed based on the number of pages processed.
* **Resume Parsing Credits**
For products aimed at Recruitment technology, such as Resume Parsing, Job Description and Candidate Search & Match, credits are calculated per document. This reflects the specialized AI models and processing methods unique to these use cases. See Resume Parsing Credits for more information.
**Custom usage arrangements are available for Enterprise customers.**
Contact the Affinda Sales team to discuss aligning credit usage with your specific operational needs and value outcomes.
### Reviewing credits usage
You can review your organization's credits usage in the Billing section. Only users with the **Owner** role have access to view billing information and credit usage details.
### Viewing usage by workspace or document type
The usage graph can display credit consumption broken down by workspace or by document type, alongside the organization-wide view. Select the dimension you want on the usage graph to switch between views.
This is useful for allocating usage across teams, clients, or products. For example, organizations that on-bill document processing to their own customers can see exactly which workspace or document type generated the usage.
Breakdown data accumulates from the date this feature was released. Usage from before that date appears in the organization-level totals but is not back-populated into the workspace and document type breakdowns.
### Classification-only
A Document Type can be configured to only classify the document and skip any data extraction steps. Due to the lower processing costs associated, credit usage is capped at **3 credits per document,** regardless of page count. For example: 1 page = 1 credit, 5 pages = 3 credits, 20 pages = 3 credits. To enable this setting on a Document Type, please email [support@affinda.com](mailto:support@affinda.com).
### Selective page processing by document type
You can now configure Affinda to process **only a continuous page range** from your documents, instead of processing every page by default.
Page selection is defined **per document type**, giving you precise control over what gets processed and billed.
Excluded pages are not processed and **are not charged**.
Examples:
* **Invoices**: process only pages 1–3
* **Contracts**: process only pages 2–5
* **Reports**: apply a custom page range specific to that document type
This feature is enabled by the Affinda team. Once configured, the rules are applied automatically during processing, with no changes required to your existing workflows.
For more information or to enable selective page processing, please email [support@affinda.com](mailto:support@affinda.com).
## Payment
Affinda offers a number of payment options to scale with your business.
### **Payment methods**
Organization Owners can manage payment methods from the Billing page. From there, you can add a card, view saved card details, set a default payment method, or remove a saved card.
The default payment method is used for future credit purchases and automatic invoice charges where applicable.
### **Invoice history**
Organization Owners can view invoices from the Billing page under Invoice History. The invoice table shows the invoice date, invoice number, amount, and status.
To download an invoice, open the actions menu on the invoice row and select Download PDF. Invoices appear here after purchases or billing cycles are issued through Maxio.
### Pay-as-you-go
Customers can purchase additional credits through the Billing page in their organization.
1. Select the number of credits you’d like to purchase.
2. Complete your payment securely through Maxio Payments. If your organization already has a saved payment method, you can use it for future credit purchases.
With Auto-Reload, when your credit balance drops below a preset threshold (e.g. 50 credits), the system will automatically top up your account. This prevents service interruptions and removes the need to monitor credit levels manually.
### Billing in Arrears
For business users, Affinda provides monthly billing in arrears.
Great for scaling operations with predictable costs. Only pay for what you use, and as your volume increases, your cost per document decreases.
[**Get in contact**](https://www.affinda.com/contact) with the Affinda Sales team to set up Monthly Billing in Arrears
### High Volume or Custom Packages
If you're interested in purchasing a higher-tier package or exploring custom pricing options, [please reach out to the Affinda Sales team.](https://www.affinda.com/contact)
We can add tailored credit packages directly to your organization, allowing you to complete payment securely via our existing platform. Alternatively, we’re happy to accommodate standard invoicing if preferred.
# Affinda Agent
Source: https://docs.affinda.com/configuration/affinda-agent
Use the Affinda Agent to set up and configure your document processing workflow through a natural language conversation.
The Affinda Agent is an AI assistant built into the Affinda platform that helps you go from sign-up to a fully configured document processing workflow in minutes. Instead of navigating settings and configuration screens manually, you describe what you need in plain language and the agent does the work for you.
The agent can:
* **Set up a workspace** for your specific use case
* **Configure document types** based on your sample documents, suggesting and iterating on fields and data sources with you
* **Create validation rules** by translating your business logic into working rules
* **Set up integrations** to export data to downstream systems
* **Explain platform concepts** and point you to the relevant documentation, or search the web when your question goes beyond the platform
The Affinda Agent configures your real workspace and document types as you talk. Every change it proposes can be reviewed, adjusted, or rejected before it takes effect — you stay in control throughout.
## What you can do with the Affinda Agent
### Set up a workspace
Describe the type of documents you process and the data you need to extract. The agent will create a workspace with the appropriate settings for your use case.
**Example prompts:**
* "I process supplier invoices and need to extract header details and line items for my ERP system."
* "I receive loan application packs that contain multiple document types — income statements, ID documents, and bank statements."
* "I want to set up a workspace for processing customer onboarding forms."
The agent will ask follow-up questions where needed. For example, whether you need document splitting enabled, what OCR settings are appropriate, or whether classification should be turned on, and configure the workspace accordingly.
The more context you give the agent about your use case, the better it can tailor the configuration. Mention the types of documents you receive, what data matters to you, and where the data needs to go.
### Configure a document type for your workflow
Upload one or more sample documents and the agent will help you build a document type around them. It analyses your documents, suggests fields for extraction, and lets you iterate on the schema together.
Share one or more representative documents with the agent. Aim for a variety of formats and layouts rather than multiple copies of the same template — this gives the agent more to work with when suggesting fields.
The agent analyses your documents and proposes a set of extraction fields, including data types and any relevant structure (such as table fields for line items).
Discuss changes with the agent in natural language. You can ask it to add, remove, rename, or restructure fields.
Once you're happy with the fields, the agent applies the configuration to your document type. You can continue to refine it later, either through the agent or directly in the platform.
You don't need to get everything right in one go — add fields, adjust settings, and refine your schema across multiple messages. If your fields use picklists or need to map against reference data, you can also ask the agent to create and manage [data sources](/configuration/picklists) as part of the same conversation.
### Create validation rules
Describe the business logic you want to enforce and the agent will generate validation rules for you.
The agent translates these into working validation rules and applies them to the relevant fields. For more on how validation rules work, see [Validation Rules](/configuration/validation-rules).
Once your extraction and validation are configured, you can also ask the agent to set up [data export integrations](/configuration/agent-integrations) — describe where your data needs to go and in what format, and the agent will configure the integration for you.
### Ask for help with platform concepts
If you're unsure about a concept or setting, ask the agent. It can explain how features work and direct you to the right documentation.
The agent draws on the full Affinda documentation to give you accurate, contextual answers. It can also search the web when your question goes beyond the platform.
You can ask the agent about concepts at any point during setup — not just in a dedicated Q\&A session.
# Configure integrations with the Affinda Agent
Source: https://docs.affinda.com/configuration/agent-integrations
Configure integrations with the Affinda Agent to build no-code data exports to downstream systems using natural language instructions.
This feature is currently in **beta** and may change as we gather feedback. Functionality, behavior, and availability are subject to updates, and there may be occasional bugs or limitations.
Integrations with the Affinda Agent let you export data from the platform to other applications without writing any code.
See our [Tutorial: Creating your integration with the Affinda Agent](/handbook/agent-integrations) for a comprehensive step-by-step guide.
## How credentials work across integration types
When you configure an integration through the Affinda Agent, there are two ways to connect to a downstream system:
**Pipedream-connected apps**
For apps in Pipedream's library (Xero, Google Sheets, Outlook, SharePoint, and thousands of others), credentials are managed by Pipedream. You connect your account through Pipedream's OAuth flow — Affinda never sees or stores your credentials for these connections. Pipedream processes API requests but does not store or log request payloads or response data.
**Manual pathway**
For any downstream system with an API endpoint, the Affinda Agent writes custom integration code that runs on Affinda's platform. Use [Secrets](#secrets) to store any API keys or credentials your integration needs to authenticate with the downstream system.
## Pipedream
The Affinda Agent uses Pipedream, a third-party platform, to offer thousands of integrations off the shelf. Pipedream handles the permissions and authentication required to export data from Affinda to other applications. To use Pipedream-connected apps, users will need to make an account with Pipedream — find their documentation [here](https://pipedream.com/docs).
## Basic Configuration
**Connected Account**
To create an integration, the user should first connect their account of their downstream application to Affinda using Pipedream. Users can create an integration that uses a single connected account or multiple.
**Workspace and document Type**
Integrations are tied to a specific workspace and document type. They will only execute on documents belonging to both those groups.
**Trigger**
Each integration requires a trigger; users can choose between document-parse completed or document validated.
## Agent
Users can describe their data export requirements in natural language, and the Affinda Agent will create the code required to complete the integration.
**Test run**
Once the integration code has been generated, the user can run a "test run" with existing documents to see if the integration behaves as expected.
**Integration Failed**
If your integration ran into an error, the "Fix in Chat" button passes the error message back to the agent to self-correct. Alternatively, you can view the run logs to manually review.
## Secrets
The Secrets section in integration settings lets you store API keys and credentials securely for use in integrations built on the manual pathway.
Secrets are stored encrypted and are never visible after creation.
**Where to find it:** Open an integration and go to the **Settings** tab. The Secrets section is listed at the bottom.
Secrets are injected as environment variables into your integration code and can be referenced using the key name you assigned.
Secrets apply to integrations built on the manual pathway only. For integrations using Pipedream-connected apps, credentials are managed by Pipedream and do not appear in this section.
## Enabling Integration
Once you are happy with the performance of your integration, you can enable it by toggling on the blue switch in the Configure Integration Interface or in the Workflow Settings > Data Export.
# Extract checkbox selections from forms
Source: https://docs.affinda.com/configuration/checkboxes
Capture selected and unselected options from forms with checkbox fields in Affinda, including configuration options for grouped and individual checkboxes.
Checkbox extraction in Affinda allows you to extract important information on forms, contracts, and other structured documents where selections or options are indicated using checkboxes.
Affinda supports 2 types of Checkbox Extraction:
Use this when one or more options can be ticked, returning the label (text) of each checked box for the relevant category.
Use this when there is a single checkbox, returning True if it is checked and False if it is not. This field type will not have a 'rectangle' on the document.
### When adding checkboxes as a new field, existing documents will need to be reparsed for the model to identify the ticked checkbox on the document.
# Document Classification
Source: https://docs.affinda.com/configuration/classification
Configure Affinda's document classification to automatically route incoming files into the correct document type for downstream extraction and workflows.
Document classification is the process of automatically identifying and categorizing documents based on their content or metadata. In the Affinda platform, document classification ensures that documents are correctly categorized into their relevant type. This is a foundational step in document processing workflows, as accurate classification enables targeted and optimized downstream actions relating to data extraction, validation, and post-processing settings.
## Detailed Tutorial for Validating Classification
Click here for Affinda Academy tutorial
## Configuring Classification
Classification behavior can be configured in the **Workspace Settings**.
The classification model will assign a classification from the set of document types configured in your workspace.
### Auto Classification
When enabled, Affinda will classify and route each document to the relevant Document Type when uploaded to a Workspace. If the document is uploaded to a specific Document Type, Affinda will not attempt to re-classify automatically.
If disabled, documents sent to a Workspace will remain unclassified until updated by a user.
### Reject Documents
Workspaces can be configured so that Affinda automatically rejects documents that are not of the right type. These documents will be sent to the 'Rejected' list in the app, where they can be reviewed and moved to the appropriate Document Type by a user.
Document rejection will occur in the following cases:
* If a document is sent to a Workspace and no relevant Document Type is found within the Workspace
* If a document is sent to a specific Document Type, and the classification the model returns does not match the Document Type
## Default Classification Model
The default classification model is a self-learning system that improves over time. When a new document is uploaded and needs to be classified, the model uses two key inputs:
1. **Document Type Names and Descriptions**
The names and descriptions provide the model with an understanding of the general characteristics and unique traits of each Document Type.
2. **Reference Documents from Model Memory**
The Model Memory offers examples of previously confirmed documents, helping the model identify patterns and similarities. See Model Memory page for more information.
### By combining this contextual and example-based information, the model can make informed classification decisions. Therefore, it is crucial that:
* The **name** and **description** of each Document Type accurately reflect the types of documents it will receive. These can be changed in the Configure Document Type interface.
* All documents added to Model Memory are **correctly classified**, as they directly influence future classification accuracy.
## Fast Classifier for Resume Parser customers
This non-learning model is optimised for performance on Resumes and Job Descriptions in particular and is the default classifier used for all customers with a Recruitment Technology use case.
## Custom Classification Model
For customers with bespoke requirements that the above options do not meet, the Affinda team can create a custom classification model. [Get in touch with the Affinda team to learn more about this option. ](https://www.affinda.com/contact)
# Field and document confidence scores
Source: https://docs.affinda.com/configuration/confidence
Understand how Affinda calculates field-level and document-level confidence scores, and how to use them to drive automation and validation rules.
Affinda provides confidence scores for data extracted to help you assess the reliability of data extracted from your documents. Rather than using a confidence value from the model that does not strongly reference the data from the documents validated by users, our approach to confidence is to provide significantly higher weight to validated documents of a similar format to the uploaded document.
Confidence Scores, when available, are shown in the Affinda app when you hover over the yellow dot next to an unconfirmed field:
## Benefits
* Confidence is not calculated without the context of other validated documents. Instead, it pays particular attention to the data from very relevant documents
* The ceiling for how confident the model can be in the predictions is much higher (up to 99%)
## Limitations
* While our method of calculating confidence delivers strong results when using Affinda's platform at scale, it will take 2-3 examples of the same document format before confidence will be returned on fields
## How Confidence is Calculated
When users upload a document, our Fingerprinting algorithm identifies suitable reference document(s) from [Model Memory](/configuration/model-memory) that are provided to the model to help guide the extraction.
Whenever someone validates data from a processed document, we store the data results as our "ground truth" for confidence calculation. Accuracy is measured by comparing the model's predictions with validated annotations.
For each new document, we look at the accuracy results from up to the last five validated documents that used the same reference document. An overall accuracy score is calculated for each extracted field.
## Setting Confidence Thresholds
Affinda can support both field-level and global confidence thresholds.
**Field-level:** Users can configure a specific confidence threshold by creating a validation rule in the app. For example, "@Date of Establishment confidence is >80%"
**Global:** Affinda can support **global confidence thresholds** to enable auto-validation of:
* **Fields** that meet the global threshold.
* **Documents** that meet the global threshold.
Global thresholds are **not currently supported** through validation rules. To enable for your workspace, please [reach out to the Affinda team. ](https://www.affinda.com/contact)
### FAQs
If there are no prior validated data for that document format, we provide annotations without a confidence score.
Only one validated document per reference is required to begin showing confidence scores.
# Document status reference and transitions
Source: https://docs.affinda.com/configuration/document-status
Reference for every document status in Affinda, including processing, ready for review, validated, and rejected, and how documents move between them.
The Document Status feature helps users manage and track documents efficiently through their lifecycle in the platform. Each document can have one of the following statuses:
## For Review
Documents marked as For Review require human validation. These documents have not passed automatic validation and are queued for manual verification.
## Confirmed
Documents in Confirmed status have successfully undergone validation, either automatically by Machine Validation or manually by Human Validation. These documents are ready for further processing.
## Archived
The Archived status allows you to remove documents from active views without deleting them from the platform. Documents can be archived directly from either the 'For Review' or 'Confirmed' tabs. This status is typically used once documents have been processed and exported downstream.
## Rejected
Documents are labelled 'Rejected' when they have been manually or automatically marked as invalid. Automatic rejections may occur due to the following reasons, depending on workspace-specific settings:
* Duplicate submission of an existing document
* Irrelevance of the document type for the specific workspace
# Remove duplicate documents
Source: https://docs.affinda.com/configuration/duplicates
Configure Affinda's de-duplication to detect and remove duplicate documents during ingestion, keeping your workflows clean and avoiding double-processing.
Settings for removing duplicates can be found for each workspace in the **Workflow Settings** under ‘Pre-processing'. If Affinda identifies a duplicate and the setting is enabled, the document will be automatically updated to be **Rejected**. The user can still manually override and place the document back into a Workspace if required.
Affinda uses Document Binary Match to detect and reject duplicates. Documents with matching fields (e.g the same Invoice Number) will not be rejected by enabling Remove Duplicates. To do this, users will need to support this logic on their side and can utilise our APIs to delete unwanted documents.
### Different versions of the same document are not classified as duplicates.
Affinda inspects the document metadata to identify if the exact duplicate of the document has been previously uploaded to the Workspace. Documents re-submitted as a new version will not be classified as a duplicate.
# Upload documents via email
Source: https://docs.affinda.com/configuration/email-upload
Configure a dedicated inbox to upload documents to Affinda via email, including handling attachments, sender allowlists, and routing to document types.
Uploading documents via email is a convenient solution for those who want to set up automated document ingestion without building an integration. It allows the data extraction process to fit seamlessly into existing workflows.
The process is simple; all customers need to do is attach their documents to an email and send them to a specific email address provided by us. Our system will automatically extract the attachments and apply our AI models to process them accordingly.
Email addresses to use for uploading documents can be found in the **Workspace Settings.**
* Each Workspace will have a **unique** email address associated with it
* Email addresses can be refreshed for security reasons by pressing the refresh icon
* The API response will include the email address from which the document was received from
* An allowlist can be configured so that only documents from approved email addresses/domains are processed
### Upload limit of 10 attachments per email
Any emails sent with more than 10 attachments will not be processed by Affinda
# Export extracted data from Affinda
Source: https://docs.affinda.com/configuration/export-data
Compare ways to export extracted data from Affinda, including the API, webhooks, Affinda Agent integrations, CSV downloads, and direct integrations.
Exporting data enables the extracted information to be utilized in downstream applications and systems. Affinda offers four primary methods for exporting data: manual export via the app, API-based export, webhooks, and integrations.
## File formats
Data can be exported from Affinda in 3 different formats:
* JSON (default)
* XML
* CSV
CSV export is not supported for resumes given the complex data structure
The format and schema of these files are dynamic according to the fields for the document type being exported.
* **Document types without tables or repeating groups**\
The CSV export is simple: each document is represented as a single row, with each field or metadata value stored in its own column.
* **Document types that include tables or repeating group structures**\
The CSV export contains multiple rows per document. Each row corresponds to an entry in the table or group, while the document-level fields (like document name, date, etc.) are repeated in each row to maintain context.
CSV export is not recommended for any Document Types containing more than 1 Table or Group field.
## Export method
Data can be exported from the Affinda solution either via the app or programmatically.
### Manual Export
Manual export allows users to download extracted data directly from the Affinda platform for offline use or to import into other systems. This option is generally more suitable for users requiring occasional or small-scale exports.
To export via the Affinda platform, navigate to the document list within the workspace, select one or multiple documents, choose the desired export format, and download the file.
### Programmatic Export
Most high-volume users will export their data programmatically via our API, workflow tool, or integration. This option is ideal for developers looking to automate their document processing by automatically adding the exported data to their downstream systems.
For more information about using the Affinda API and the integrations available, see the [API Reference](/reference/getting-started).
### Frequently Asked Questions for Data Export
CSV export will replicate the order of your fields in the Document Type Configuration Interface; reorder them to adjust the order of your exported CSV file.
# General Field Configuration
Source: https://docs.affinda.com/configuration/field-configuration
Configure field properties in Affinda such as data types, required flags, default values, and parsing rules so extracted data matches your downstream schema.
Field configuration settings allow users to customize how data is extracted, processed, and displayed in Affinda's platform. These settings ensure the extracted data meets specific requirements and can be easily integrated into downstream workflows.
Field configuration options can be accessed by Workspace Owners and Admins by clicking 'Configure Fields' in the top right corner of the document validation view.
## Detailed guide for Schema Design
Click here for Affinda Academy tutorial
## Basic Configuration
### Field Name
The field name represents the label for the extracted data in the validation UI. It is user-defined and helps the model in extracting the field from documents; as such, it is important to have clear and relevant field names.
### Field Description
Users may optionally enhance the model's predictions by providing additional context, such as how the data is typically labelled and where it appears on the page.
**Adding more documents** is the recommended way to enhance model accuracy. However, a clear field description can also improve extraction results
A practical guide to writing effective field descriptions, with eight patterns for fixing common extraction mistakes.
The field description and Text Options serve different purposes. The **field description** guides the model on *what* to extract from the document — for example, "Extract the billing address, not the supplier's address." **Text Options** control *how* the extracted value is formatted in the output — for example, trimming whitespace, normalising dates, or stripping trailing characters. If the model is extracting the correct text but the format is wrong, use Text Options. If the model is extracting from the wrong place on the document, refine the field description.
The field description controls *what* the model extracts from the document. If you instead need to control *how* the extracted value is formatted in the output (for example, trimming whitespace or normalising dates), use [Text Transformations](/configuration/standard-fields#text-transformations).
## Data Types
Your field's data type determines how extracted values are processed and standardized. Different data types are available to ensure that structured and unstructured data is correctly categorized. The selected data type influences the structure of the data and the post-processing logic applied to extracted values, ensuring consistency and accuracy.
Text, Numbers, Dates, Location, Phone Number, URLs
Groups and Tables
Options and Data Source
Labels and True/False
Signatures, Seals, and Headshots
If the raw data extracted from the document is unable to be logically parsed into a format consistent with the data type selected, no parsed value will be returned. Edit the annotation to improve extraction accuracy, or in the case where the bounding box is correct, edit the value directly by typing the correct value
## Basic Field Settings
### Enabling Fields
This setting determines whether the field should be predicted and visible in the extracted output. Users can toggle this option depending on whether they want the model to extract and display the field.
Disabling a field instead of deleting it lets the model keep all previously validated annotations and automatically restores them when the field is re‑enabled.
### Multiple Values
Enable multiple predictions only when a field can have **multiple distinct values** within a single document. Examples include:
* Line item tables on an Invoice
* Parties or Signatories in a Legal Contract
* Transactions in a Bank Statement
Enabling multiple values where you would generally not expect multiple distinct values in a document can reduce model accuracy (by overpredicting values) or risk noise and confusion in review workflows due to the presence of duplicates.
**Rule of thumb:** if there should only be one real value (even if it appears multiple times on the same document), stick to a single value. Only enable **multiple values** when the document structurally allows or expects multiple *distinct* values.
## Advanced Field Settings
### No rectangles
Used when a field value does not explicitly appear in the document but can be inferred through reasoning.
### Manual entry only
The field will not be predicted by the model and can only be entered manually.
### Slug
Defines the unique label used for the field in the API response.
## Re-parsing after changes to the Schema
When you make changes to the Document Types configuration, any documents that were parsed previously (both confirmed and documents in review) need to be re-parsed.
The Affinda app identifies documents that should be re-parsed, indicated by the reparse button turning orange in the top right-hand corner when opening the document in the Document Validation View. Clicking on this button will update the extraction to the latest document type configuration.
# Glossary of Affinda platform terms
Source: https://docs.affinda.com/configuration/glossary
Definitions of key Affinda platform terms, acronyms, and concepts used across the documentation, including extraction, validation, and workflow terminology.
## Platform Structure
Consider an Organization as a central hub that contains all your Workspaces, Document Types, and uploaded documents which are accessible when you log into the Affinda platform. Typically, the name of your Organization matches the company name provided during initial registration.
Within Affinda, an Organization functions as a collaborative space accommodating multiple users. The Organization Owner, who initially sets up the trial account, can manage the accounts of other users, assigning and adjusting their access to specific queues as necessary.
If your company's Organization account already exists, it is recommended to create additional user accounts directly within user settings. Inviting colleagues in this manner allows them immediate access without having to complete the trial registration process.
A Workspace enables you to organize related document processes efficiently. Each Workspace can handle one or several Document Types and is typically used as a broader organizational structure, representing either a specific client (useful for business process outsourcing companies) or a particular department within your organization.
A Document Type defines a category of documents that you wish to classify and extract information from. Documents of the same type should have similar structural and semantic characteristics, and require extraction of the same fields. This grouping allows for consistent and efficient use of extraction rules or models. Common examples include invoices, purchase orders, and bank statements.
**Collection** is a legacy term that was previously used to refer to what is now called a **Document Type**. If you encounter references to "Collection" in older documentation or system interfaces, it refers to the same concept as Document Type.
## Concepts
\*\*OCR (Optical Character Recognition) \*\*is the technology that converts text in scanned documents or images into machine-readable text. In Affinda, OCR enables the platform to extract and process data from non-editable files like PDFs and images.
An advanced algorithm that identifies similar documents by analyzing unique textual and visual features. This creates a distinctive 'fingerprint' for each document, enabling precise matching and retrieval of relevant examples from Model Memory. These examples are then provided to the model to enhance accuracy and context awareness when processing newly uploaded documents.
Model Memory is a validated set of reference data and documents that Affinda's models use to enhance accuracy over time. By leveraging Retrieval-Augmented Generation (RAG), Model Memory enables Affinda to dynamically reference previously validated documents, allowing the model to predict future documents more accurately without requiring constant retraining.
A process where human input is included in an AI-driven workflow to review, correct, or approve results. In Affinda, this typically occurs during the **validation** stage, where users verify and adjust extracted data to ensure accuracy before it's used downstream.
This approach combines the speed of automation with the accuracy and judgment of human oversight. Affinda offers a simple and intuitive interface for HITL.
The manual labeling of data fields by drawing a box over the field in documents to help train or refine the AI model.
The process of reviewing and finalizing a document in the Affinda validation interface. When a document is *confirmed*, it signals that all extracted data has been reviewed and is accurate—no further changes are needed. Confirmed documents are used by the Model for continuous learning to improve accuracy.
## Affinda Functions
The process of automatically separating a multi-document file (like a PDF with multiple invoices) into individual documents for more accurate processing.
The step where Affinda identifies and labels the type of each document (e.g., invoice, resume, contract) to then route it to the correct workflow and extraction model.
The process of identifying and pulling out specific data fields (such as names, dates, amounts) from a document into a structured and usable format.
Extracted data can be validated automatically using data mappings and rules to ensure accuracy, or manually reviewed through a human-in-the-loop process.
# Configure table and group fields
Source: https://docs.affinda.com/configuration/group-table-fields
Use group and table field types in Affinda to extract repeated structured data such as line items, transactions, and nested objects from your documents.
## Table Fields
Table fields capture repeating sets of related data in a document — typically one row per item, each containing the same set of fields (e.g. description, quantity, amount).
Affinda supports both **classic grid-style tables** and **more irregular or nested layouts**. Clean, column-based tables are handled using **Grid** mode, while stacked or semi-structured rows are handled using **Freeform** mode.\
\
You don’t need perfectly aligned layouts; as long as each row follows a consistent pattern, a table field can extract it effectively.
## Creating tables
The most efficient way of creating tables is to draw a box around a table on the document (excluding any header rows) when in Field Configuration. Affinda will instantly recognise the table structure, as well as the child fields or columns within the table, and create these fields for you. You can add, remove, and edit table columns the same way you would regular fields.
Alternatively, you can create a table manually by:
From within the document validation interface, select 'Configure Fields' in the top right corner
Select 'Add Field' in the left panel
Once the data type has been configured to a table on the parent field, an option to add child column fields will be provided in the left panel.
Create a field for each of the columns you want to include in your extraction. For each, give a descriptive name like "unit" or "line total" and select the relevant data type.
### **Reviewing extracted data from tables**
To understand how to use our table editor, see [Table Editor Tutorial.](/academy/table-editor)
## Group Fields
Group fields in Affinda are dynamic objects that can include any other data type as children. They help organize related fields under one umbrella, allowing for more structured data extraction and processing. This is ideal when dealing with complex documents where related data points need to be grouped.
Examples of group fields include:
* **Resumes:** Group fields to structure work experience entries with job title, company name, and employment dates
* **Legal Documents:** Group party details such as name, role, and contact information for each party involved
* **Forms:** Organize repeated information blocks like references or emergency contacts.
**Tip: Only use a group field when you expect several different versions of the same set of fields and need to keep the data from each version together.**
If the related fields appear **only once**, leave them as regular fields and place them under a header instead. Group fields should *always* be multiple.
### Creating Group Fields
The process for creating Group fields is simple.
From within the document validation interface, select 'Configure Fields' in the top right corner
Either draw a box around an entire group on the document or select 'Add Field' in the left panel
Once the data type has been configured to Group on the parent field, an option to add Child fields will be provided in the left panel. Users can then add any child fields and configure their settings.
# Image fields and signature extraction
Source: https://docs.affinda.com/configuration/images
Use image field types in Affinda to extract logos, signatures, photos, and other visual elements as cropped images alongside text data from documents.
Affinda models can identify Signatures, Headshots, and Seals in your document using our image detector. Within the API, we will return a url of the image extracted from the document. The presence of this url can be used to signal that the particular image type exists on the document, or the image can be downloaded and added to your system.
Returns the image of the signature. The presence of the parsed value can be used to verify that a document contains a signature.
Returns the image of the headshot or person.
Returns the image of the seal of authenticity. The presence of the parsed value can be used to verify that a document contains a seal of authenticity.
### When adding images as a new field, existing documents will need to be reparsed for the model to identify the image on the document.
For extraction of other image types, [please contact Affinda to learn more.](https://www.affinda.com/contact)
# Document Ingestion Options
Source: https://docs.affinda.com/configuration/ingestion
Compare ingestion options for sending documents to Affinda, including the web app, API, email upload, and direct integrations with cloud storage providers.
There are 3 main ways to upload documents to the Affinda platform. Documents can be ingested through multiple channels, depending on the user's workflow:
Uploading documents manually via the Affinda app
Automatically fetching documents from a linked email account. \
\
See [Email Upload](/configuration/email-upload) for more information
Ingest documents from other systems such as CRMs or ERPs using API integrations or workflow automation tools.\
\
See [API Reference](/reference/getting-started) for more information.
Affinda assigns each document a **unique identifier** during ingestion, ensuring traceability throughout the workflow.
## Supported Formats
**Text-based formats:** PDF, DOC, DOCX, XLSX, ODT, RTF, TXT, HTML
**Image-based formats:** PNG, JPG, TIFF, JPEG
**Best Practices for Document Ingestion**
* Use **high-resolution** scans or images
* Files should ideally be **uncompressed** to ensure optimal extraction accuracy
# Automated Machine Validation for Extracted Data
Source: https://docs.affinda.com/configuration/machine-validation
Use Affinda's machine validation to automatically approve high-confidence documents and route low-confidence cases to human reviewers for full automation.
Validating the data extracted from documents is a critical part of the Affinda workflow, ensuring the accuracy and reliability of data sent downstream. Machine Validation assesses whether extracted data meets predefined conditions and ensures that user review is only required by exception to deliver significant efficiency gains.
## Key Components of Machine Validation
Affinda utilizes two primary methods for machine validation, often most effective when combined.
Data mapping is a powerful capability aimed at enhancing the quality and accuracy of data extracted from documents. With data mapping configured, the extracted data can be mapped against a list of known options from the customer's own data to validate that it meets expected values. This provides greater confidence in the data extracted by the model and ensures seamless integration with downstream systems.
Unmatched data triggers user review, prompting manual correction or alternative actions.
See [Picklists](/configuration/picklists) for more information.
Business-specific rules and logic can be customized based on document type, fields extracted, and unique use cases. Validation rules offer flexibility, accommodating criteria such as:
* Mandatory fields
* Model confidence thresholds
* Expected data formats
* Relationships between document fields
* Other custom business logic
See [Validation Rules](/configuration/validation-rules) for more information.
## Machine Validation Settings
Auto-confirmation can be enabled at a Workspace level in the **Workflow Settings.** When enabled, documents that pass all validation rules are automatically confirmed, eliminating the need for manual review.
Auto-confirmed documents are not used in Model Memory.
# Model Memory: learn from past corrections
Source: https://docs.affinda.com/configuration/model-memory
Learn how Affinda's Model Memory feature uses past corrections to improve extraction accuracy over time without requiring full model retraining.
Model Memory is a validated set of reference data and documents that Affinda's models use to enhance accuracy over time. By leveraging Retrieval-Augmented Generation (RAG), Model Memory enables Affinda to dynamically reference previously validated documents, allowing the model to predict future documents more accurately without requiring constant retraining.
## Key Benefits of Model Memory
* **Continuous improvement** – The model improves over time by referencing validated documents, ensuring better predictions without the need for extensive manual adjustments.
* **No need for constant prompt engineering** – Instead of adjusting prompts for every case, Model Memory provides a more scalable approach to improving AI performance.
* **High accuracy for repeated formats** – The system quickly learns and perfects the extraction for recurring document formats, such as invoices from a particular supplier.
## How It Works:
* When a new document is uploaded, Affinda’s Fingerprinting algorithm scans Model Memory to find sufficiently similar documents.
* If relevant documents are found, one or more of these validated examples are provided to the model.
* The model uses these documents to improve extraction accuracy and consistency.
By using this method, Model Memory provides the model with real-world examples, reducing the likelihood of errors and continuously improving the accuracy of document processing.
## Managing Model Memory
### Options for automatically adding documents to Model Memory
Users can control how documents are automatically added to Model Memory through the Workspace Settings in the Affinda app. There are three options:
1. **Auto (Default Option)** – Affinda intelligently selects which documents are added.
2. **Manual** – No documents from the workspace are automatically added to Model Memory, even after validation.
3. **Always** – Every validated document from the workspace is added to Model Memory.
**Auto** is the recommended option for most Workspaces intended for ongoing model learning. Under these settings, document formats not already well-covered in Model Memory are intelligently selected, ensuring:
* The memory does not grow excessively large, making it easier to audit.
* The model remains efficient by avoiding redundant examples of well-represented formats.
### Manually updating documents in Model Memory
The above setting determines which documents get added to Model Memory when they are Confirmed. However, Organization Admins retain the ability to add or remove documents from Model Memory independent of this setting. This provides a mechanism for users to further control and improve model performance.
Documents can be added or removed from Model Memory though the Document List view within a Workspace. This can be applied as an action on a single document, or as a bulk action.
## Importance of Highly Accurate Data in Model Memory
Since Model Memory directly references individual documents and their validated data, the accuracy of annotated documents is critical. Incorrect or low-quality annotations can lead to:
* **Confusion in model predictions** – The model may reference incorrect information, leading to erroneous outputs.
* **Propagation of mistakes** – Since Model Memory applies learnings from past documents, any errors will be replicated in future extractions.
**Best Practices for Ensuring High-Quality Data**
* **Use the Auto mode for document selection** – This ensures a manageable and auditable dataset.
* **Correct errors promptly** – Any errors discovered downstream should be corrected in the Affinda app to maintain data integrity.
* **Establish clear validation guidelines** – If multiple team members validate documents, create clear annotation standards to prevent inconsistencies, especially in cases where ambiguity exists.
**By following these best practices, organizations can maximize the effectiveness of Model Memory and achieve unparalleled accuracy in document processing.**
## Re-parsing after adding Model Memory documents
Once you add more documents to your **model memory**, the model learns from them and can make better predictions on similar examples in the future.
Affinda will automatically identify documents that could benefit from this improved accuracy. For these documents, the **Reparse** button in the **Document Validation View** will turn **orange**, indicating that the model recommends you reparse the document to take advantage of the new learnings.
If accuracy drops on a document type that was previously extracting well, the first thing to check is the **Model Memory reference**. From the Document Validation interface:
* Click the three-dot icon in the top right corner
* Select Model Memory Reference to view the confirmed document the model used as its reference.
If that reference has incorrect annotations, correct them, re-confirm the reference, and then reparse the affected documents.
## Frequently Asked Questions about Model Memory
The user can see the model memory document referenced in each new document processed by clicking on the three dots in the left-hand corner of the **Document Validation Interface**, then selecting 'Model Memory Reference'. This will open the confirmed document used by the model in prediction extractions. Users can make corrections to the reference document in this view.
Yes. In Affinda, **Model Memory works like a living reference library**: every document you validate is stored and later surfaced by the fingerprinting algorithm to guide new extractions. The more high-quality, diverse documents you keep in that memory, the greater the chance the model finds a close match and pulls the right examples, so accuracy improves without retraining.
Just make sure the memory grows with *relevant* and correctly annotated files—Affinda’s recommended “Auto” mode keeps only representative samples so the memory doesn’t become bloated with duplicates, which could reinforce errors.
If you spot a mistake in a document that’s already sitting in Model Memory, it's important you correct it promptly. Locate the document under the confirmed documents tab and open the Document Validation UI. Adjust the wrong annotations (drag them to the right spot or redraw them) and then click "Confirm Document".
Now you have corrected the error; you should re-parse any documents in the "For Review" tab to reapply the extraction model and prevent the propagation of mistakes.
# Model performance dashboard
Source: https://docs.affinda.com/configuration/model-performance
Use correction data from human review to find the fields, document types, and Model Memory references driving the most rework, and prioritise the configuration changes that improve accuracy.
The Model Performance dashboard turns human corrections into a prioritised list of things to fix. It shows which document types, fields, and Model Memory reference documents are generating the most rework, so you can target field descriptions, settings, and Model Memory instead of guessing.
The dashboard is most valuable if human review is part of your business-as-usual workflow. Correction volume is only a reliable accuracy signal where reviewers are consistently checking and confirming documents.
A correction is a field-level event where the current annotation differs from the original model prediction. Field confirmations with no change to the value, selection, or count are excluded.
## Overview tab
Filter the whole view by date range, workspace, document type, type of human change, and issue type. Three summary metrics sit at the top:
* **Human corrections** – total correction events across the fields in scope.
* **Docs corrected** – the share of documents in scope that needed at least one correction.
* **Field issues** – the number of distinct fields with corrections.
### Cumulative coverage
Shows how concentrated the correction burden is across fields. In most configurations a small group of fields accounts for the majority of corrections, which tells you how much of the problem you can solve with a handful of changes.
### Main issue type breakdown
Correction volume split by the kind of change the reviewer made:
| Issue type | What it means |
| ------------------------------- | ----------------------------------------------------------------------- |
| **Missing fields** | The model did not return a value and the reviewer added one. |
| **Extra fields** | The model returned a value the reviewer removed. |
| **Wrong selection or location** | The right field was returned, but from the wrong place on the document. |
| **Wrong value or cleanup** | The value was edited, reformatted, or cleaned up. |
The mix matters when deciding what to change. Missing and extra fields usually point to an unclear field description or a schema that does not match the document. Wrong selection or location usually points to a Model Memory reference that is not a close match to the documents being processed.
## Field detail
Open any field to see:
* **Field description** – the instruction used for future predictions. Edit and save it directly from this panel. Changes affect all future extractions for that field.
* **Issue type distribution** – the same four issue types, scoped to this field.
* **Evidence** – individual correction events showing the original model prediction next to the reviewer's annotation, with surrounding row context for table fields. Filter by failure mode, search across evidence, open the source document in the review interface, or export the full set to CSV. Reading the before and after values across several examples usually makes the fix obvious. A field that is repeatedly captured from the wrong region needs a description that states where the value sits. A field that is repeatedly reformatted needs the expected format written into the description, or a text transformation.
Work top-down. Fix the highest-volume field first, let new documents flow through, then come back and check whether the correction count has fallen. Small numbers of corrections spread across many fields are rarely worth chasing.
## Model memory tab
Reference documents are ranked by the number of corrections made on the documents that used them, alongside how many documents used each reference and the average corrections per document. Documents parsed without any reference are reported separately.
A reference document at the top of this list is a signal, not a verdict. There are three common explanations:
1. **The reference has inaccurate annotations.** Errors in a Model Memory document propagate to every document that references it. Open the reference, correct the annotations, re-confirm it, and reparse the affected documents.
2. **The reference is a poor choice for Model Memory.** It may be an unusual or low-quality example that is being matched too broadly.
3. **A closer match is missing.** The fingerprinting algorithm selected the best available reference, but no reference closely resembles the incoming format. Confirm a representative document of that format and add it to Model Memory. Average corrections per document is the more useful column when comparing references, since total corrections is partly a function of how often a reference is used.
See [Model Memory](/configuration/model-memory) for more on how references are selected and managed.
## A suggested working rhythm
1. Set the date range to your last review period and leave the other filters open.
2. Use the cumulative coverage chart to decide how many fields are worth addressing.
3. Work through the top fields, reading the evidence before changing anything.
4. Update field descriptions, settings, or validation rules based on what the evidence shows.
5. Check the Model memory tab for reference documents with a high average corrections per document, and correct, remove, or supplement them.
6. Reparse affected documents so the changes apply to work already in the queue.
7. Return the following period and compare correction volume on the fields you changed.
## Related pages
* [Model Memory](/configuration/model-memory)
* [Improving accuracy: a deep dive into extraction models](/handbook/improving-accuracy)
* [General Field Configuration](/configuration/field-configuration)
* [Validate extracted data in the review interface](/configuration/user-validation)
# OCR and Text Extraction
Source: https://docs.affinda.com/configuration/ocr
Learn how Affinda performs OCR (optical character recognition) and text extraction across PDFs, scans, and images, including supported languages and quality.
Affinda's solution is designed to work effectively on both machine-readable documents and scanned images and files. For scanned images or documents where textual information is contained within images (e.g., logos), Affinda uses Optical Character Recognition (OCR) to convert the images into machine-readable data ahead of classification and data extraction.
## OCR Options
Affinda provides four different options for customers that dictate whether OCR is applied to each document. While applying OCR on documents can increase overall performance, it adds additional processing cost and time (0.5 - 1 seconds per page), so applying OCR might not be suitable for all use cases.
By default, new Workspaces will have 'Auto-Detect' OCR enabled.
OCR is never applied, even if no text layer is found. Suitable for use cases where speed/cost is most important. Not recommended for most use cases.
Applied to documents where no text layer is found within the document. Affinda will apply OCR over the entire document if fewer than 25 words are in the text layer of the document. The text extracted from the document will overwrite any existing text layer. If a text layer with over 25 words is found, OCR will not be applied.
OCR is applied to elements of the document without a text layer to all documents uploaded. This preserves the original machine-readable text but also extracts additional information from images and pages in the document without this text layer.
A typical example is an invoice where the supplier name and business number are contained within the header image/logo. Combining both the text layer and OCR-extracted text ensures comprehensive results.
OCR is applied to all documents and is used in place of any existing machine-readable text layer. Typically, only recommended when the text layer in a document is frequently incorrect and needs to be corrected.
If extraction is producing duplicated text, garbled output, or wildly incorrect values despite the document looking fine visually, the PDF may have a corrupted or duplicated text layer.
In this case, set OCR to **Always Full OCR** at the Workspace level to force OCR from the image layer. To apply OCR to a single document, click the three-dot icon in the top right of the Document Validation interface and select **Apply OCR**.
## What if the text layer on a document is incorrect?
From time to time, a document may be submitted that has a text layer that does not perfectly match the data in the document itself. Whilst this is uncommon, it means that Affinda has not applied OCR technology and thus we will not be able to accurately extract the data.
In the rare cases where this occurs, users can click the three-dot icon in the top right corner of the Document Validation interface and click 'Apply OCR, ' which will apply OCR to the document and re-parse the data.
Clicking 'Apply OCR' will reparse the full document. Users will need to reconfirm fields and the document after the reparse.
# Picklist fields for constrained extracted values
Source: https://docs.affinda.com/configuration/picklists
Configure picklist fields in Affinda to constrain extracted values to a fixed list of options, including hard-coded, dynamic, and API-driven picklists.
## Overview
Affinda’s data-mapping capability lets you normalise extracted values against your own lists, giving you cleaner data and fewer downstream corrections.
## When to choose each type
| Data Type | Data format | Value prediction mechanism |
| ----------- | ----------------------------------------------------------- | ------------------------------------------------------- |
| Options | Short, fixed list (≈ 50 values or fewer) | Model predicts the value directly |
| Data Source | Larger, often two-dimensional list from a downstream system | Raw data from the document matched by string comparison |
## Options
A field whose **Data Type** is set to **Options** stores a single column of permitted values. Enter the items directly in the field editor. Any value outside this list is flagged during validation.
**Best practice tips**
* Keep the list concise.
* Use consistent casing.
* Review periodically to remove unused terms.
## Data Sources
Data Sources serve as lightweight master data tables that you can manage directly within Affinda. Affinda supports CSV, XLSX or JSON files as Data Sources, meaning you can upload anything from supplier registers to nested product catalogues.
Data Sources and Model Memory are often confused but serve different purposes. Data Sources are used for **mapping and enrichment** — matching extracted values against your reference data. They do not train the extraction model. [Model Memory](/configuration/model-memory) is the feature responsible for improving extraction accuracy over time. In short: Model Memory teaches the model *what* to extract, while Data Sources validate *whether* the extracted value matches your known data.
### Creating a Data Source
A *key column* is the single field in your source table whose values are guaranteed to be unique; it is used by Affinda to reliably identify each record unambiguously.
The *label* is the human-readable name stored for each record in a Mapping Data Source; it's what users will see in the validation UI and drop-downs.
### Learn from user feedback
Under Data Source options, users can enable **Remember selections**. When enabled, the platform records the confirmed value for a given raw-text extraction and automatically reuses that value the next time the same text appears in a new document. This helps speed up future searches, improve suggestions, and ensures user validations contribute to ongoing performance gains.
**Remember Selections** is particularly useful when extracted values consistently differ from your reference data — for example, abbreviated supplier names.
When a user confirms a match that differs from the raw extraction, Affinda learns it as a mapping for future documents.
This option is **enabled by default** for every new Data Source field.
### Automating updates
Call `PUT /data-sources/{id}` for full replacement or `PATCH /data-sources/{id}` for incremental updates. Schedule these calls from your integration.
### Mapping document fields
A *key column* is the single field in your source table whose values are guaranteed to be unique; it is used by Affinda to reliably identify each record unambiguously.
The *label* is the human-readable name stored for each record in a Mapping Data Source; it's what users will see in the validation UI and drop-downs.
* **Exact** – strings must be identical.
* **Partial** – succeeds when the extracted string appears anywhere in the candidate.
* **Fuzzy** – edit-distance logic allows minor typos.
### Tips for reliable matching
* Trim whitespace and normalise case in your source files.
* Ensure the key column is unique.
* Keep label strings short so they fit comfortably in the UI.
### API reference
```http theme={null}
GET /data-sources # List
POST /data-sources # Create
PUT /data-sources/{id} # Replace all rows
PATCH /data-sources/{id} # Update selected rows
DELETE /data-sources/{id} # Delete
```
# Pre-Processing Overview
Source: https://docs.affinda.com/configuration/preprocessing
Overview of pre-processing steps Affinda applies to incoming documents, including format conversion, deskewing, OCR, splitting, and classification.
Pre-processing involves the automated cleaning, organizing, and structuring of uploaded files to prepare the documents for data extraction.
## Importance of Pre-Processing
By ensuring documents are well-prepared before extraction, pre-processing
* Reduces the likelihood of errors in later stages
* Improves the speed and accuracy of data extraction
* Enables the seamless handling of various document types and formats
## Key Pre-processing Actions:
* **Invalid File Handling:** Identify issues that mean a document cannot be processed, such as insufficient text in the document, unsupported file types, corrupted files, or password-protected documents.
* **File Format Conversion:** This involves converting file formats (e.g., images, PDFs with embedded data) into a PDF format suitable for processing.
* **Remove Duplicates:** Workspaces can be configured to identify and reject documents that have already been processed. This can be configured by the user in Workflow Settings; see [Remove Duplicates](/configuration/duplicates) for more information.
* **OCR (Optical Character Recognition)**: Extracting text from scanned or image-based documents using advanced OCR technology, ensuring high accuracy for all document types and formats. See [OCR and Text Extraction](/configuration/ocr) for more information.
* **Language Detection:** Automatically identifies the language of the document to ensure high-accuracy extraction.
Pre-processing settings can be found in your Workspace *Workflow Settings*.
## Advanced Pre-processing Settings:
**Reading Order Model:** The Affinda Platform uses our proprietary reading order algorithms by default to capture word sequences in visually rich documents in a way that aligns with human comprehension. This ensures that text is processed in the same order a human would read it, leading to more accurate extractions.
**Split Words:** Ensures words that are incorrectly combined are separated for extraction. Default is on.
# Redact sensitive data and PII from documents
Source: https://docs.affinda.com/configuration/redaction
Configure document redaction in Affinda to mask or remove sensitive data such as PII before exporting redacted versions of documents downstream.
While the most common export from the Affinda platform is structured data to be ingested into a downstream system, Affinda also offers document redaction capabilities on any document type. With these redaction capabilities, we edit the PDF so that the original text is completely removed and not just masked by an overlay.
Click here for information about our pre-configured Resume Redactor.
## Configuring a Document Type for redaction
The steps to create a new Document Type that is suitable for redaction are very similar to those required for the typical extraction of structure data.
1. [Follow this tutorial to create your new Document Type](/academy/model-creation)
2. Edit every field to ensure 'Allow Multiple Values' (found in Advanced Settings) is enabled (this ensures that if a field is repeated within the document, each version is redacted)
3. Upload documents to view fields to be redacted in the document validation interface
4. (optionally) Edit and update model predictions
5. Use the **Get Redacted Document** endpoint to return a redacted PDF version of the original document
Get in contact with the Affinda team to discuss your redaction use case and to enable a 'redaction' setting on your document type that will optimise for this output
## Exporting redacted file via API
```bash theme={null}
curl -L -X GET "https://api.affinda.com/v3/documents//redacted" \
-H "Authorization: Bearer " \
-o redacted_.pdf
```
### Frequently Asked Questions about Redaction
To ensure the model redacts every version of the field on your document, you need to enable 'allow multiple' in your fields configuration.
To do this, go to your Configure Document Type Interface >Locate your field > navigate to Advanced Settings > enable "Allow Multiple Values"
For Redaction, we recommend setting all fields to "Allow Multiple Values" to avoid this issue.
The performance of the redaction is determined by the performance of the underlying extraction model. To improve, we recommend adding more example documents and validating correct example documents to build Model Memory.
Follow the [Improving Model Accuracy Tutorial](/academy/improving-accuracy) for step-by-step instructions.
# Automatic splitting of multi-document PDFs
Source: https://docs.affinda.com/configuration/splitting
Configure Affinda's automatic document splitting to break up multi-document PDFs into individual files for separate classification and extraction.
Document Splitting is a powerful feature that allows you to separate a single file containing multiple documents into individual documents for further processing. This is especially useful when working with batch-scanned files.
Once split, each document inherits the Workspace’s classification and extraction rules, simplifying downstream workflows.
## Detailed Tutorial for Validating Splitting
Click here for Affinda Academy tutorial
## Splitting Settings
Configure splitting settings at the Workspace level by navigating to *Workflow Settings*.
Click on the toggle to enable the automatic splitting of files, then select the splitter you would like to use.
If splitting isn't working, first check that a splitter is selected in Workflow Settings — not just that the toggle is enabled.
### General Document Splitter
All customers will have access to Affinda's General Document Splitter. This model has been designed to identify specific cues that indicate a new document, including:
* Change in page numbering sequence (e.g. Page 1)
* Change in key party within the document (e.g. an invoice from a different supplier is identified)
* Change in key document identifier
### Custom splitter
While the General Document Splitter has been designed to work across most use cases, there will be some use cases that will need additional configuration. Two different types of custom splitters can be created:
1. **LLM based**\
Design a prompt that details when a file should be split
2. **Key word**\
Split when a specific keyword(s) is found on a page
[Reach out to the Affinda team](https://www.affinda.com/contact) if the General Document Splitter is not meeting your use case, and you want to discuss a custom splitting model.
## What happens to documents that are split?
When a document is split into multiple components, new files are created in your account. These new files are created with a suffix added to the file name (e.g. \[filename]\_1, \[filename]\_2, etc.).
Within the API response of the original file, users will also be able to find the identifier of the new files created, so that they can then request the data extracted from these newly created files. The PDF file of the documents is also included in the response so that new documents created can be added to your platform.
## Editing the splitting
While the document splitter automatically splits a document, users will still have the option to manually edit the splitting or combine documents again through the 'Edit Pages' option within the document validation UI. This gives users full control over their documents.
If there are any edits made to the file, the AI model will re-parse the affected documents to give the most accurate predictions. Any field validations made will be lost.
See the [**Tutorial: Reviewing splitting and classification**](/academy/split-classify) for step-by-step instructions.
# Standard field data types and parsing rules
Source: https://docs.affinda.com/configuration/standard-fields
Reference for Affinda's standard data types including text, number, date, currency, and boolean, with parsing rules and supported formats for each.
Your field's data type determines how extracted values are processed and standardized. Different data types are available to ensure that structured and unstructured data are correctly categorized. The selected data type influences the structure of the data and the post-processing logic applied to extracted values, ensuring consistency and accuracy.
### Show Raw Values
Affinda stores two versions of every extracted field: raw (exact text from the document) and parsed (after data-type formatting and other transformations). Both are included in data exports. In the app’s **Document Validation** interface, only the parsed value is shown by default. To show raw values alongside it, open a document, click the three dots in the top-right, and select "Show Raw Values".
Once enabled, the raw value will be shown in italics underneath the parsed value.
## Text
Raw text is retained as-is with no special formatting. Suitable for general strings, labels, or descriptions.
Users can adjust the following text type options:
* **Standardize bullets:** Removes bullet point formatting from extracted values.
* \*\*Include line break: \*\*Maintains the line breaks from the original text in the extracted data.
### Text Transformations
Transformations allow users to refine extracted text by applying a natural language prompt. Users can specify how they want text to be cleaned, reformatted, or transformed for better usability. Affinda processes transformations using either:
* Large Language Models (LLMs) for dynamic text refinement
* Code-based transformations, where possible, ensuring minimal variability in standardized data
Text Transformations and the [field description](/configuration/field-configuration#field-description) serve different purposes. Use the field description to guide the model on *what* to extract from the document (for example, "Extract the billing address, not the supplier's address"). Use Text Transformations to control *how* the extracted value is formatted in the output (for example, trimming whitespace, normalising dates, or stripping trailing characters).
## Numbers
Formats values into numbers. Users can adjust the number of decimals returned via Decimal Options in the Field Configuration view.
## Dates
All Date Data types standardize dates into ISO 8601 format (YYYY-MM-DD and hhmmss). Affinda supports 3 date structures:
* Date
* Date/time
* Date Range
### Date Options
**Date Format Disambiguation** - Specify how the model should interpret ambiguous date formats (e.g., 03/04/2024). Choose the format that best matches your regional preference—**DMY** for UK-style dates or **MDY** for US-style dates.
**Expected Tense** - improve predictions by indicating the expected tense of the date (Past or Future).
**Default Day and Month** - Select the default for when dates are missing a day or a month.
## Location
Geocoding is applied to identify and structure the address into street, city, country, etc. fields
Users can adjust the following Location options:
* **Expected Country**: Improve predictions by specifying the country you expect to find in the document.
## Phone Number
Structured to include country code, international country code, formatted number and national number in the response.
Users can adjust the following Phone Number options:
* **Default country code**: Specify the default country code when one isn't found on the document.
## URL
Identifies the url link and the domain
# User Management and Permissions
Source: https://docs.affinda.com/configuration/user-management
Manage users, roles, and permissions in the Affinda app to control who can upload documents, validate extractions, configure models, and export data.
Within the Affinda platform, teams can collaborate to configure their workflow and document types and to process documents on an ongoing basis.
## User Permissions
### Organization Permissions
At an Organizational level, Affinda has three levels of permissions.
Can manage other Users, Workspaces, Document Types, and Billing
Can manage other Users (except for Owners), Workspaces, and Document Types
Their only role is to validate documents within Workspaces for which they have been granted permission. Members cannot change any settings (unless they have been added as Workspace Admins - see below)
### Workspace Permissions
Can update all Workspace settings. By default, all Organization Owners and Admins are implicitly Workspace Admins. Organization Members can be added as Workspace Admins to allow for the management of teams processing documents.
Cannot update any settings.
Workspace Members' permissions can be controlled at the organizational level in the **Organization Settings**.
Owners and Admins can configure if Workspace Members can:
* Upload documents
* Edit file names
* Reparse documents
* Apply OCR
* Manage Tags
## Adding New Users
To invite new Users to your Organization, navigate to the '**Members**' settings from your Organization homepage. The invited User will receive an email inviting them to accept the invitation, at which point they will be prompted to either log in to their existing account or register a new account.
Users can also be removed by clicking the 'X' button next to their role.
There must always be at least one Owner for an organization.
## Workspace Permissions
By default, all organization members have access to every workspace in the organization; however, a Workspace can be set to 'Private' so that only certain team members will be able to view the Workspace. All Organization Owners and Admins will have access to all Workspaces, and only Members must be explicitly added to private Workspaces.
To update Workspace permissions, navigate to 'Permissions' within the relevant Workspace. You will also be able to create Workspace Admins.
# Validate extracted data in the review interface
Source: https://docs.affinda.com/configuration/user-validation
Review and correct extracted data in the Affinda document validation interface, including keyboard shortcuts, side-by-side viewing, and bulk approval.
Affinda’s document validation UI provides an intuitive and efficient tool for reviewing the data predicted by Affinda’s AI models and making any necessary adjustments. It has two main purposes:
1. **Ensuring 100% accuracy** – while Affinda’s models are highly accurate, there may be data that needs human review. The validation UI allows this ‘human in the loop’ to correct any inaccuracies to ensure that the data is accurate before being exported for downstream processing.
2. **Creating a self-learning feedback loop** - any corrections made in the validation UI can be used to improve model performance over time. Documents confirmed by users may be added to [Model Memory](/configuration/model-memory), providing a reference set of documents that can be provided to the model when new documents are uploaded. This ensures that accuracy starts off high, and then improves as your model learns the formats commonly processed.
It is important that users using the validation UI ensure that the tool is used consistently and accurately to avoid any model regression.
## Detailed Tutorials for User Validation
Click here for Affinda Academy tutorial
Click here for Affinda Academy tutorial
Click here for Affinda Academy tutorial
## Field Indicators
The following symbols indicate the status of each data field:
1. **Green Lightning Bolt:** Field has been automatically confirmed, meeting all validation criteria.
2. **Green Checkmark:** Field has been manually confirmed by a user.
3. **Orange Dot:** Field has not yet been validated and requires manual review.
4. **Red Flag:** Field has failed one or more validation rules and needs correction.
## Document Queue Management
The Affinda Platform has been designed so that teams can process documents simultaneously. To ensure that effort is not duplicated, controls have been implemented to stop two users working in the same document:
* After a user confirms a document, the next document in the queue that is not being looked at by another user will be presented
* In the cases where multiple users have the same document open, the user who opens the document last will have a warning displayed to notify them of another user in the document
# Custom validation rules for extracted data
Source: https://docs.affinda.com/configuration/validation-rules
Apply custom validation rules in Affinda to enforce business logic on extracted data, flag errors before export, and gate documents for human review.
Within the Affinda platform, validation rules can be configured to automatically check whether extracted data meets predefined business logic. When these rules pass, the data is considered valid and does not require user review, enabling straight-through processing for compliant documents.
Validation rules not only support model accuracy but also help identify documents that fail to meet business requirements.
In the validation interface, users can see which rules have passed (auto-validated fields are marked with the bolt icon) and which have failed, clearly indicating where human review is needed.
## Creating validation rules
Affinda allows you to create powerful, flexible validation rules using natural language prompts. Simply describe the business logic you want to apply, and Affinda will automatically generate th e code needed to enforce it, no manual coding required.
### **Steps to Create a Validation Rule**
In the document validation interface, click “Configure Fields” in the top right corner
Either select the pencil icon on the field you want to apply logic to or click the Validation tab, then select "Add Validation Rule".
To reference specific fields, type @ and choose from the list. Validation rules can be created with just one or multiple fields.
Clearly describe the condition or constraint. Add detail for more complex logic.
Rules are created with the annotated field in the opened document as an example.
As a best practice, create validation rules on documents that accurately reflect how the fields usually appear.
Affinda will produce the corresponding rule logic based on your description.
After generation, you can review the underlying code, tweak the prompt, and re-generate the rule as needed to refine the behavior.
## Pass and fail messages
When you generate a rule, Affinda also creates default messages to display when the rule passes or fails. These messages are shown to users in the validation UI and help explain the outcome of the rule.
You can customize these messages by including guidance in your natural language prompt—for example, specify what the pass/fail messages should say to make them clearer or more specific for end users.
Example: “Ensure the invoice date is before the due date. If not, show: ‘Due date cannot be earlier than invoice date."
## Missing data handling
In the Advanced Settings, users can define how a validation rule should behave if one or more of the referenced fields are not predicted. This is especially useful for rules involving multiple fields, where some fields may be optional or not consistently extracted.
**Available Options:**
* **Skip**\
The rule is skipped entirely—no pass or fail outcome is recorded.
* **Fail**\
The rule automatically fails if any required field is missing.
* **Pass**\
The rule is marked as passed, regardless of missing fields.
* **Ignore**\
The rule runs by treating missing fields as neutral, attempting to return a valid result based on available data.
* For example, useful in cases like subtotal + freight + tax = total, where freight is occasionally absent.
## Built-in validators
For a set of common standardised field types, Affinda provides built-in validators that perform real-time cross-checks or format/checksum verification, including a live lookup against the [Australian Business Register](https://abr.business.gov.au/) for ABNs.
To enable a built-in validator, add a validation rule on the relevant field with a prompt in the form:
```text theme={null}
@field_name is valid X
```
Replace `@field_name` with the field reference. Affinda automatically maps the rule to the appropriate built-in validator based on the field type.
**Supported validators:**
| Validator | Check |
| ------------------------- | -------------------------------------------- |
| ABN | ABN resolves to a current, active ABR entity |
| ACN | ACN ASIC checksum |
| IBAN | IBAN country format + MOD97 checksum |
| BIC | BIC/SWIFT ISO 9362 syntax + country code |
| VIN (format) | VIN 17-character format |
| VIN (format and checksum) | VIN format + check digit |
## Required fields
A common validation use case is ensuring that certain fields are always present and extracted from a document. To streamline this process, Affinda automatically generates a “required field” rule for every new field created. This rule can then be quickly enabled with a single click.
## Validation rule results
Validation rule results are surfaced to users in the validation UI, showing users which rules have passed (and therefore which fields have been auto-validated) and any failed rules that need user attention.
For more information, see [User Validation](/configuration/user-validation).
# Configure your document workflow
Source: https://docs.affinda.com/configuration/workflow
Configure each step in the Affinda document workflow, including ingestion, splitting, classification, extraction, validation, and export rules.
Within Affinda's platform, we offer a configurable workflow designed to flexibly meet customers' document processing requirements. While most workflows share common steps, each step can be adjusted to align with your organization's unique processes.
The workflow begins by uploading documents. Documents can be added through three primary methods:
* **Email Upload:** Attach documents directly to an email inbox configured to your workspace. [(Learn more)](/configuration/email-upload)
* **Integrations:** Use APIs or other integration services to upload documents programmatically. [(Learn more)](/reference/getting-started)
* **Drag and Drop:** Manually upload documents by dragging and dropping into the workspace
The uploaded documents then undergo various pre-processing steps. During this stage, OCR is applied to extract text from image files, invalid document types are identified and rejected, duplicates are detected, and several other essential processes are performed to prepare documents for further processing.
See [Pre-Processing Overview ](/configuration/preprocessing)for more information.
Document splitting provides the option to automatically separate a single file containing multiple documents into individual documents for further processing.
See [Document Splitting ](/configuration/splitting)for more information.
Next, documents are automatically classified into the relevant document types. Classification helps route each document to the appropriate extraction model efficiently.
See [Document Classification ](/configuration/classification)for more information.
Affinda's AI models extract relevant information from your documents. Users can create multiple information extraction models tailored to different document types and configure the fields and formatting required for each type. We use a combination of Large-Language Models, our [Model Memory ](/configuration/model-memory)concept, and an advanced Fingerprinting algorithm to ensure optimal performance that improves over time.
Following extraction, documents undergo Machine Validation. Here, predefined rules and checks ensure that extracted data meets your accuracy and consistency criteria. Errors or anomalies are flagged automatically, significantly reducing manual verification workloads.
See [Overview of Machine Validation](/configuration/machine-validation) for more information.
When automated validation identifies potential issues or edge cases, documents enter a User Validation stage. In this step, human reviewers confirm or correct the extracted data using our Document Validation UI, ensuring the highest levels of accuracy before data is sent downstream.
See [User Validation](/configuration/user-validation) for more information.
Finally, structured data is exported. Affinda provides different export formats and a variety of tools to make integrating Affinda into downstream systems easy.
See [Exporting Data](/configuration/export-data) for more information
# Data retention policies and controls
Source: https://docs.affinda.com/data-retention
Configure how long Affinda retains uploaded documents and extracted data, including retention periods, deletion controls, and compliance considerations.
## Document Deletion
By default, documents uploaded to Affinda will be retained indefinitely to ensure that users can continue to request this data.
However, customers maintain full control over these documents, and these can be deleted at any time using one of the two methods below:
* **Deletion**\
When a document is deleted, the document and all associated files are immediately removed from our servers. All access to the document will be lost. Document metadata, which may include file names but does not include the file content, may remain in Affinda’s database or backups of Affinda’s database for some time.
To delete through the Affinda App, first reject the documents in Affinda by selecting the documents and clicking the bin icon. Then navigate to the rejected tab and select the documents again, and select "Delete Forever".
Delete documents through the API by using the [Delete Endpoint. ](/reference/getting-started)
* **Expiration**\
The Affinda API allows a customer to specify an expiry time when they submit the document (or update this after submission). When a document has an expiration date set, it will be automatically deleted on that date.
## Deleting an Organization
Deleting your Affinda Organization will remove all data and documents associated with that account from Affinda. To delete your Organization, navigate to Organization Settings in the web application.
## Deleting a User
To delete your user account, navigate to your user settings (in the top right corner of the platform) and select 'Delete my account'.
# Deployment and Data Residency
Source: https://docs.affinda.com/deployment-data-residency
Affinda's regional server locations, data residency controls, and enterprise deployment options for AU, EU, and US data sovereignty requirements.
## Server Locations and Data Residency
Affinda offers multiple app instances with different server locations. Available regions include **Australia (Global)**, **United States (US)**, and **European Union (EU)**.
* New users are **automatically routed to the correct Affinda app instance** based on their location.
* The **sign-up form clearly indicates** which instance users are creating an account in.
* Users who attempt to log in to the **wrong instance will see a banner** suggesting the correct one. In addition, your API key only works on the instance where it was generated. (e.g. if you signed up at [app.us1.affinda.com](http://app.us1.affinda.com), use [api.us1.affinda.com](http://api.us1.affinda.com).)\
Each instance can be accessed using the following links:
| Region | App URL | API base URL |
| ----------- | ------------------- | ------------------- |
| AU (Global) | app.affinda.com | api.affinda.com |
| US | app.us1.affinda.com | api.us1.affinda.com |
| EU | app.eu1.affinda.com | api.eu1.affinda.com |
* **Data Residency Controls:** We can enforce restrictions to ensure no data leaves a specific region (e.g., prevent cross-region inference).
### Please contact us to discuss changing server locations or enforcing data residency controls.
## Enterprise Deployment Options
For enterprise customers, Affinda provides additional flexibility by offered dedicated tenants that are fully isolated environments tailored to your organization, or private cloud deployments.
[**Get in touch with**](https://www.affinda.com/contact) our team to learn more about enterprise deployments.
# Error glossary and troubleshooting
Source: https://docs.affinda.com/error-glossary
Reference for common Affinda API and platform errors, including likely causes and recommended fixes for upload, parsing, and validation failures.
| **Error** | **Explanation** |
| :------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| duplicate\_document\_error | Document has been rejected due to an existing duplicate in the workspace. (Condition: 'Reject duplicates' setting is enabled for the workspace.) |
| no\_text\_found | Affinda didn't find any text on the document. This error often occurs when image files are uploaded to Affinda. |
| insufficient\_text\_found | Error raised when documents contain no extractable text, even after OCR processing.
This typically occurs with images such as photos of people or objects, which do not contain readable text. |
| file\_corrupted | The file uploaded to Affinda was corrupted |
| unknown\_error | Raised when parsing fails due to internal extraction issues.
The cause can vary and requires investigation. As an immediate step, try reparsing the document.
If the issue persists, please contact the Affinda team for further analysis. |
| file\_too\_large | The maximum file size that can be uploaded to Affinda is **20MB**. |
| document\_classification\_failed | Document rejected does not match any of the configured document types in the workspace. This means you have enabled 'Reject Documents' under classification in the workspace settings. If this is not desired behaviour, switch this setting off. |
| invalid\_file\_type | Affinda supports a wide range of file formats for document processing: **Text-based formats:** - PDF, DOC, DOCX, XLSX, ODT, RTF, TXT, HTML **Image-based formats:** - PNG, JPG, TIFF, JPEG |
| no\_parsing\_credits | You have run out of credits in Affinda. Go to your Organization's Billing page to purchase more credits. Once you have purchased more credits, simply reparse the document. |
| parsing\_deleted\_documents | This error is raised when attempting to reparse a document that has already been deleted. |
| capacity\_exceeded | Affinda's capacity has been exceeded by requests at that time. Wait a few moments and reparse the document to resolve. |
| document\_conversion\_failed | Affinda, as part of its document preprocessing, converts the uploaded file to a readable PDF format before extracting details. If this conversion fails—due to a timeout or an issue with the document—an error is raised. In such cases, try reparsing the document or uploading a new copy. |
| password\_\_protected | The document you have uploaded to Affinda is password-protected and cannot be accessed. |
| file\_not\_found | This error is raised when the document has not been preprocessed and saved in Affinda for parsing, or if the document has been deleted and a reparse has been requested.
In such cases, please reupload the document to parse. |
| incorrect\_document\_type | Raised when an unsupported document type is uploaded to a specific Document Type Extractor.
For example, uploading invoices to a Resume Parser extractor. |
| parse\_terminated | Parsing the document you have uploaded has exceeded our document timeout limits. If you are running into this issue frequently, due to large or dense documents,[ get in contact with the Affinda team](https://www.affinda.com/contact) to discuss custom timeout limits. |
| parsing\_failed\_timeout | The error raised when documents exceed the timeout limit during parsing. This often occurs during bulk uploads where the wait: true parameter (default) is used.
In most cases, reparsing the document will resolve the issue. |
| requires\_ocr | Raised when a document requiring OCR encounters issues during automatic OCR processing.
In most cases, clicking on the three dots in the top menu bar and selecting 'Apply OCR' will reparse the document with OCR and resolve the issue. |
# Frequently asked questions
Source: https://docs.affinda.com/faqs
Answers to common questions about the Affinda platform, including pricing, supported document types, accuracy, integrations, and security practices.
## Account and Security
Yes. Users can configure MFA by navigating to their Profile Settings (click the user icon in the top left corner) and clicking "Set up MFA". Affinda supports both email and authenticator apps.
If you would like to require MFA for all users in your organisation, [reach out to the Affinda team](https://www.affinda.com/contact), and we can enable this security requirement.
For more on Affinda's certifications and data handling, see our [security & compliance overview](https://www.affinda.com/security).
Affinda doesn't limit the number of users you can add to your organization
Affinda is ISO27001:2022 certified and SOC 2 Type 2, GDPR and HIPAA compliant.
## Capabilities
Affinda supports over 50 languages, including the following:
| **Language Code** | **Language** |
| :---------------- | :---------------- |
| En | English |
| De | German |
| Ja | Japanese |
| Es | Spanish |
| Fr | French |
| It | Italian |
| Pt | Portuguese |
| Zh-tw | Chinese (Taiwan) |
| Zh-cn | Chinese (PRC) |
| Nl | Dutch |
| Pl | Polish |
| Sv | Swedish |
| Cs | Czech |
| Ru | Russian |
| Da | Danish |
| Ro | Romanian |
| No | Norwegian |
| Id | Bahasa Indonesian |
| Hu | Hungarian |
| Tr | Turkish |
| Hr | Croatian |
| Sk | Slovak |
| Fi | Finnish |
| Vi | Vietnamese |
| Th | Thai |
| Sl | Slovenian |
| El | Greek |
| Et | Estonian |
| Ar | Arabic |
| Ko | Korean |
| Lt | Lithuanian |
| Fa | Persian |
| Bg | Bulgarian |
| He | Hebrew |
| Uk | Ukrainian |
| Tl | Tagalog |
| Mk | Macedonian |
| So | Somali |
| Lv | Latvian, Lettish |
| Sq | Albanian |
| Af | Afrikaans |
| Sw | Swahili |
| Bn | Bengali |
| Hi | Hindi |
| Ur | Urdu |
| Mr | Marathi |
| Gu | Gujarati |
| Ta | Tamil |
| Ne | Nepali |
| Ml | Malayalam |
| Te | Telugu |
| Kn | Kannada |
| Pa | Punjabi |
Yes, Affinda supports multilingual documents.
The default page limit in Affinda is 20 pages per document. If you need to increase this to fit your use case, [get in contact](https://www.affinda.com/contact) with the Affinda team.
All data exports include a `rawText` field containing the full, unstructured text extracted from the document.
For every field Affinda extracts, you’ll get two values:
* **raw** — the value exactly as it appears on the document.
* **parsed** — the value after data-type processing and text transformations (e.g., date/number normalization).
After splitting is enabled, the original multi-document file remains available as the “parent” record, and each piece of it becomes a “child” document. The parent–child relationship means you can still access the full set of pages and see which children were created. In practice, when a file is split Affinda creates new files with suffixes on the filename (e.g., `[filename]_1`, `[filename]_2`).
In the app, you can use the “Edit Pages” function to split or combine pages again.
Affinda's fingerprinting algorithm uses both textual and visual content to construct a representative embedding of the document's meaning and layout. This includes not just the physical aspects (layout, text location, formatting) but also analyzes the semantic meaning of the text itself.
Affinda requires you to configure a document type to extract data off your document. To do so, see [Creating a New Model](/academy/model-creation).
You can do this quickly by letting the model intelligently suggest fields for you.
Simply,
1. Upload one document
2. Create a new document type
3. Select "Set up fields for me", the model will anaylse the content of your document to extract the key fields
4. Click "Finish configuration" and see the data extracted off your documents
5. Upload more documents of the same type to see your data extracted
Yes, Affinda can extract table data, preserving the relationship between data belonging to the same row.
To extract tables, you need to first define your table field.
1. Navigate to a document with a table you want to extract
2. Click "Configure fields" in the top right corner
3. Create a new field and set the data type to Table
4. Add the column fields you want to extract eg. "description", "unit" or "total"
5. Click "Finish configuration" and reparse the document
See [Groups and Tables](/configuration/group-table-fields) in the configuration guide for more information.
For tips on how to correct and validate table data, review the [Tables Editor](/academy/table-editor) tutorial.
## Configuration
Yes, Affinda is completely configurable, so you can add custom fields as you like. See [Field Configuration](/configuration/field-configuration) to see how to add custom fields to your document types in Affinda.
Affinda does not currently support creating calculated fields within the app; however, we are working towards it on our product roadmap. For the time being, Affinda can support your calculated fields by automating the extraction of the source fields in a structured and usable format, so you can build calculated fields in your own systems.
Absolutely - Affinda's allows customers to create validation rules using a natural language description of the logic that they would like to implement:
1. Type your rule in plain language, referencing any extracted field with **@field\_name**.
2. Click **Generate** to create the rule and view the underlying code.
The prompt can handle a broad range of validations.
If you require more specific logic, Affinda doesn't support uploading custom code directly. Instead, you can:
* Pull the extracted data via the API,
* Run your own checks locally, and
* Push the results back to Affinda through our **Create Validation Result API** so the outcomes appear in the app and flag documents for review.
Affinda document types are built to handle multiple layouts and templates. If the information you’re extracting follows the same schema (i.e., the same fields and structure), you don’t need a new document type for each template.
However, our models perform best with simpler schemas. If the extraction schema differs significantly across templates, consider splitting them into separate document types.
By default, documents that the model doesn't match to one of the document types linked to your workspace will remain in "For Review" as unclassified. Users can review and manually classify these documents as they like.
Alternatively, users can configure their workspace so documents that are left unclassified are automatically rejected. To do this, navigate to the Workflow settings → Configure Classification and enable "Reject Documents".
## Performance & Troubleshooting
We do not publish a universal benchmark as processing time varies by document and workload.
**What you can expect, in practice:**
* Simple 1 to 3 page docs typically complete in about 30 seconds end to end.
* Medium sets, for example 5 to 20 pages or documents with many fields, often take 1 to 3 minutes.
* Heavy docs, for example long multi page tables or poor quality scans, can take several minutes.
**What drives the variance:**
* Page count.
* Field count and complexity. A dense multi table invoice is slower than a header only form.
* Pre processing needs. OCR on scans and automatic document splitting add time.
* Concurrency and queue depth when you upload in bulk.
**About bulk uploads and queues**\
If you upload many documents at once, they may enter a queue. This can add a wait before processing starts. The size of that delay depends on your concurrency, your account limits, and the current system load.
**Resume Parsing**
Our Resume Parser uses a different model type that is faster and more lightweight than our other document type models. Expected time to process a resume document is typically 2-3 seconds.
Documents uploaded to Affinda might cause an error for a number of reasons. Review our [Error Glossary](/error-glossary) to understand the error and how you can fix it.
If Affinda models are repeatedly mixing up two of your document types in classification, there are a few steps you can take to improve performance.
Firstly, ensure there are adequate examples in your model memory of both document types. Check that you have not confirmed any documents that are labelled as the wrong document type.
Secondly, check that the name and description of each document type are clear and relevant. The models use these to predict classifications. Add disambiguation hints (unique keywords, fields, or layout cues) to help the model tell similar types apart.
**Document type:** Broker Invoice
**Description:** An invoice for brokerage/origination/referral fees. Line items typically include the keywords “brokerage”, “origination”, or “referral.”
From time to time, users may hit an unexpected error when taking action in the Affinda app. If this occurs, try refreshing the page and trying again. If problems persist, get in touch with Affinda Support.
## About Us and Contact
Fill out the form [here](https://www.affinda.com/contact), and our team will get back to you.
\_Affinda specialises in enterprise AI transformations in business process automation, enabling intelligent document processing. Affinda’s AI platform, and customised solutions, automate end-to-end processes for faster, smarter operations and real productivity gains. \_
\_Affinda's document AI technology combines 10+ years of IP in document reconstruction, with the latest advancements in computer vision, natural language processing and deep learning. \_
\_Our technology is used by enterprises globally across a wide range of industries to automate their document processing workflows. \_
\_We are headquartered in Melbourne, Australia, with a global team across Asia Pacific, North America and Europe. \_
\_For more information \_[*head to our website.*](https://www.affinda.com/about-us)
Affinda offers flexible and scalable pricing plans to meet businesses' needs. For full pricing details, please head to our website pricing pages.
* [Affinda Platform pricing](https://www.affinda.com/pricing-plans)
* [Resume Parser pricing ](https://www.affinda.com/recruitment-ai-pricing)
# Create your integration with the Affinda Agent
Source: https://docs.affinda.com/handbook/agent-integrations
Use the Affinda Agent to build no-code data exports to downstream applications like ATS, ERP, and CRM systems using natural language.
## Purpose
This tutorial walks you through using the Affinda Agent to automate data export to your downstream applications. The agent takes natural language instructions, enabling users to create integrations without writing code.
Users will need to create a Pipedream account to connect to other applications for data export. Any downstream system with an API endpoint that isn't available through Pipedream can be connected via the [manual pathway](/configuration/agent-integrations#how-credentials-work-across-integration-types) using custom code and [Secrets](/configuration/agent-integrations#secrets) for credentials.
## 1. Create a new integration
Integrations are tied to a workspace and document type.
Users can create a new integration in the Affinda app by:
* Navigate to the Integration tab in your organization, and select "+ Create Integration", or
* Navigating to the Workflow settings in a particular workspace, opening the Data Export Settings, and clicking "+ Add Integration"
## 2. Connect account using Pipedream
To create an integration, users must first connect their account to the desired downstream application using Pipedream.
Use the search bar or scroll to find the service you would like to connect.
Click here to view a full list of services pipedream offers.
This will launch a Pipedream pop-up window, where you can grant Pipedream access to your account on your selected service.
Check carefully that you have granted Pipedream all required permissions; sometimes they are easy to miss.
If you have already connected to the service previously, locate the service and click on the account you wish to use.
## 3. Initial configuration
If your integration requires multiple downstream services, you can add them here.
A **trigger** is the event that starts the data export process. Users can choose from 2 triggers for data export:
* When a document is parsed, the export runs immediately after the document has been processed
* When a document is validated, the export runs only after the document is confirmed (either through manual or auto confirmation)
## 4. Create, test and fine-tune your integration code
Explain to the agent what you want the integration to do, where the data should be pushed, and what format it should be in.
The agent will ask for additional information as needed.
Once the agent has created the code, test run with an example document from your workspace.
Check your downstream apps to see how the data has been pushed.
If your integration is getting an error, click Fix in chat to send the error message to the agent. The agent will update the code accordingly.
You can also review the failed run logs in the "Runs" tab.
## 5. Enable
Once you are happy with your integration, enable it by switching on the toggle in the top right-hand corner of the Configure Integration interface. Now your integration will automatically run every time the trigger event happens.
You can also enable integrations in the Data export Workflow Settings pane.
# Writing field descriptions
Source: https://docs.affinda.com/handbook/field-descriptions
Practical guidance for writing effective field descriptions so the extraction model gets ambiguous fields right, including eight concrete patterns and a checklist.
A field description is a short instruction the model reads every time it extracts that field. It is the place to tell the model something it cannot work out from the field name or the document alone. The guidance below comes from reviewing descriptions across real projects. All examples are anonymised.
## Do you need one?
If you can write the description without looking at a document, or without a specific mistake in mind, skip it. "The date when the invoice was issued" on a field called "Invoice date" adds nothing: the model already reads the field name.
Write a description when:
* The field name is jargon or ambiguous ("Connote number", "Box 24a").
* The model got this field wrong and you can say how.
* You know something about your documents the model cannot infer.
* The field is a dropdown or a repeating group (see below).
Fix the field name first. "Invoice due date" beats "Date" plus a description explaining which date you meant.
## The eight jobs a description can do
**1. Separate lookalikes.** The most valuable move. Name the value the model confuses this field with, and say which one you want.
> "This is the vehicle identification number (VIN). Do not return the registration number, model, or make."
**2. Point at labels and locations.** Quote the literal text the value sits next to, including variants, and say where it lives.
> "Often labelled 'B/L No.', 'Ref No.', or 'Booking No.', usually at the top right of the first page."
**3. Draw the boundary.** Say exactly where the value starts and stops.
> "Date only. Do not extract the time."
**4. Permit an empty answer.** Models over-extract when they feel obliged to return something.
> "Not every document contains this field, and that is fine. Leave it blank rather than guessing."
**5. Supply facts the model cannot know.** Conventions specific to your documents or business.
> "Purchase order numbers are 9-digit strings starting with '2'."
**6. Show a good and bad example pair.** One concrete pair beats a paragraph of rules.
> "Correct: ABC123. Incorrect: 'Registration no: ABC123' (the label must be stripped)."
**7. Constrain repetition.** For fields that return multiple values, state the expected count and forbid duplicates.
> "Return each person as a separate entry. Do not merge names or repeat a name that appears in several places."
**8. Give fallback logic.** Tell the model where to look first, where to look next, and what never to use.
> "Prefer the date next to 'Effective from' or 'Effective date'. Otherwise use the date next to wording like 'This agreement was made on'. Do not use a date from the signature block."
## Style
* **One or two sentences, one failure mode.** Long descriptions are the exception, and every word is processed on every extraction.
* **Positive before negative.** "Extract X, not Y" beats a bare "Do not extract Y", which leaves the model without a target.
* **Prune when you add.** Descriptions accumulate edge cases and eventually contradict themselves. Reread the old sentences when adding a new one.
* **Any language works.** Descriptions in the document's own language perform fine.
## Dropdown (options) fields
If the labels are short or domain-specific, say what each value means:
> "Whether the deal includes an option: 'Call' (buy) or 'Put' (sell)."
If the value is inferred rather than read off the page, give the trigger for each option, including the unclear case:
> "Return 'true' if the receipt includes a meal. If there are only drinks, return 'false'. If the receipt does not say what was ordered, return 'false'."
## Grouped and repeating fields
Describe the parent, not just the children: what one instance of the group represents, and what makes two instances distinct. For groups that can repeat, add the cardinality constraint from job 7 up front ("expect at most three per document", "no duplicates"). Returning too many instances is the known failure mode.
## What descriptions cannot do
They guide the prediction. They do not reliably reformat output (use formatting options), they do not enforce constraints (use [validation rules](/configuration/validation-rules)), and they do not override your reference examples; the model reads all of these together.
## Checklist
* Says something the field name does not.
* Targets a specific mistake or a specific fact about the documents.
* Tells the model what to extract, not only what to avoid.
* Says whether an empty answer is acceptable.
* As short as it can be while still doing its job.
# Getting started with the Affinda platform
Source: https://docs.affinda.com/handbook/getting-started
Learn the basics of navigating the Affinda app: organizations, workspaces, document types, workflows, and document statuses for new users.
## Purpose
This tutorial introduces new users to the structure and core concepts of the Affinda platform. It explains how organizations, workspaces, document types, workflows, and statuses fit together, and walks through the document processing lifecycle step by step. The goal is to equip users with a clear mental model of how Affinda works, so they can confidently start uploading and managing documents.
This tutorial is designed for all new users of the Affinda platform. No technical knowledge is required.
## 1. Understanding the Affinda Structure
* **Organization**: The top-level entity where your settings, document types, billing, and members live.
* **Workspace**: A dedicated area within your organization for specific workflows and document processing tasks.
- Store your **Document Types**
- Manage **members and permissions**
- Control **billing**
- Configure **Organization-wide settings**
* Have unique workflows tailored to specific use cases (e.g., invoices, IDs, contracts)
* Display documents and their statuses
* Connect to specific document types
## 2. Document Types:
A Document Type in Affinda is a template that tells the platform how to recognise, extract and validate data from a certain category of documents- like invoice, passport or a specific type of contract.
**Created at the Organization level** – Document Types are registered at the organizational level and then linked to one or more workspaces where they’ll be used.
**Deployed per Workspace** – In each workspace, you select which Document Types apply. Affinda will only classify and extract documents using models for those selected Document Types.
## 3. Workspace Dashboard
The Workspace Dashboard is the starting point for users to commence validating documents. By default, users will be directed to view documents in the 'For Review' queue for the workspace. However, documents at different statuses (see below) or in specific document types can easily be viewed.
### Document Status
Documents uploaded into a workspace will hold one of the following statuses:
* **For Review** – Processed by the model but requires validation
* **Confirmed** – Passed validation, either through manual review or auto confirmation.
* **Archived** – No longer needed, but stored for reference
* **Rejected** – Removed from processing pipeline
### Tags
Tags can be easily added to documents to ensure easy filtering of documents. A common use of tags is to flag documents that have specific issues with them for additional review or approval.
Create new tags by clicking on the tags drop-down, typing in your label, and clicking "Create Tag".
### Adding columns and sorting
Additional columns can be added to the dashboard by clicking the cog icon in the top right corner. Column values can be sorted in ascending or descending order. This means users can review either the oldest or newest documents first.
## 4. Understanding your workflow
Documents are uploaded to a Workspace in Affinda and will follow it's configured Workflow. Let's walk through each step in the workflow and how you can configure it.
Choose how documents enter the Affinda Platform:
* **Manual Upload** – Drag and drop files
* **Email Upload** – Send to a unique email address
* **Integrations** – Use the API or other services, see [API reference](/reference/authentication) for more.
Next, Affinda applies several steps to prepare your documents before model analysis. You can
* **OCR (Optical Character Recognition) Options**: Technology that converts printed or handwritten text into machine-readable text. Select either Auto-detect (default), Partial, Full, or Skip. Learn more about what OCR setting you should use [here](/configuration/ocr).
* **Remove Duplicates** – Save wasting credits on duplicates, only removes exact document matches.
* **Advanced Options** – Choose custom reading models or enable word-splitting
Splitting in Affinda is the process of automatically separating a multi-document file (like a PDF with multiple invoices) into individual documents for more accurate processing.
Enable this to detect and split files containing multiple documents (e.g., an invoice + tax form in one file).
Classification in Affinda is the step where Affinda identifies and labels the type of each document (e.g., invoice, resume, contract) to then route it to the correct workflow and extraction model.
The platform classifies documents from the document types linked in that workspace. Our models will analyze the contents of your document against the Document type's **name** and **description.**
If a document doesn’t match any type:
* It will be marked as **Unclassified**
* You can choose to **reject or manually review** these
Each document type has a specific extraction schema that defines fields to be captured (e.g., invoice number, due date).
Affinda offers a number of ways to validate the data extracted from your document is accurate.
Users can manually validate documents through Affinda's intuitive document validation interface. Documents should be confirmed when all extracted data is correct.
Alternatively, Users can configure data mapping and validation rules to automatically validate data. Turning on **auto confirmation** will confirm documents that pass all validation rules. Documents that don't pass all rules should be reviewed by a user.
Select settings for **Model Memory**: a set of validated documents used by the model as examples. Model memory allows models to improve extraction accuracy over time, learning from your documents. We recommend **Auto mode** for most use cases (see [Model Memory](/configuration/model-memory) for more information).
Use API keys or webhook secrets to export processed data to downstream systems.
## Best Practices
* Enable document splitting if your files contain multiple documents
* Use auto-confirmation only if your validation rules are robust
* Keep model memory clean — only validated, correct documents should be saved
# Improving accuracy: a deep dive into extraction models
Source: https://docs.affinda.com/handbook/improving-accuracy
Strategies and best practices to push Affinda extraction models to 99%+ accuracy, including training data, schema tuning, and validation feedback loops.
## Purpose
Achieving "good enough" (e.g.**\~80-90% accuracy** ) is not enough for mission-critical document processing. Affinda bridges the gap to "excellent" (**99%+ accuracy**) through our approach, reducing manual work and ensuring top-tier performance.
This guide provides an understanding of how Affinda's information extraction models work and walks users through the steps they can take to uplift the performance of their models. The tutorial covers building high‑quality Model Memory with validated documents, configuring validation settings, adding field descriptions, and troubleshooting low‑performing templates to maximize extraction accuracy.
To follow this tutorial, Users should hold Organization Owner or Admin permissions.
If you have not configured your first model yet, follow the [Creating a New Model](/academy/model-creation) tutorial first.
## Under the Hood: How Affinda Extracts Data
This algorithm captures word sequences in visually rich documents in a way that aligns with human comprehension. This ensures that text is processed in the same order a human would read it, leading to more accurate extractions.
Selects and utilizes the best-performing LLMs for each task, ensuring optimal results across different document types and structures.
Uses a **retrieval-augmented generation (RAG)** system to enable continuous improvement. Corrections made in one document are instantly applied to future extractions, eliminating recurring errors without requiring extensive retraining.
See [Model Memory](/configuration/model-memory) for more information.
Identifies similar documents in Model Memory and provides relevant examples to the model, ensuring highly accurate data extraction and reducing errors.
### Benefits of Our Approach
* **No extensive model training required** – Unlike traditional ML models that require hundreds of training samples, Affinda learns dynamically and applies corrections in real-time. New, high-performing models can be created in a matter of minutes, not weeks.
* **Higher accuracy, less manual work** – Moving from 95% to 99% accuracy reduces errors by 80%, cutting down the need for human intervention significantly.
* **More intelligent than static LLMs** – Unlike generic large language models that rely on fixed prompts and lack continuous learning, Affinda actively applies nuanced learning from past interactions to make better decisions.
## Steps to Improving Accuracy
Visual Learner? Follow along with our Video Tutorial:
Affinda's models use **Model Memory** to learn from your documents and improve the accuracy of predictions.
Affinda intelligently selects a subset of your confirmed documents to use as model memory. These documents act as trusted references, helping the model make more accurate predictions on new, incoming documents.
A well-curated model memory is the foundation of **highly accurate, automated document extraction**.
> **Why this matters:**
The model will replicate what it learns from model memory. If errors are present, those mistakes will be reproduced in future predictions.
### Best Practices for Model Memory
* **Accuracy first:** Ensure extractions in model memory are **100% correct** before confirming them.
* **Correct errors promptly** – Any errors discovered downstream should be corrected in the Affinda app to maintain data integrity.
* **Establish clear validation guidelines** – If multiple team members validate documents, create clear annotation standards to prevent inconsistencies, especially in cases where ambiguity exists.
* **Quality over quantity:** You don’t need dozens of near-identical examples. Instead, aim for a **variety of documents** that reflect the range you typically receive.
* **Complete examples:** Prioritise documents that include **all required fields**, rather than ones with missing data.
By following these principles, your model memory will provide a strong foundation for consistent, accurate document processing.
Keeping these principles in mind, to build your model memory, upload representative documents.
Check the extraction of each field on the document. Correct any errors by redrawing the annotation box over the field on the document. Once the document is completely correct, click ‘Confirm document’.
To see how to validate extraction in more detail, see the [Validation - Extraction tutorial](/academy/review-extraction).
Go to Workspace Workflow Settings → ‘Configure Validation’
Here you can choose between 3 settings for model memory.
1. **Auto (Recommended)** - Affinda models intelligently select the best documents in your validated set to use as Model Memory. This keeps model memory to a finite set that can be easily audited.
2. **Manual** - No documents from the workspace are automatically added to Model Memory, even after validation.
3. **Always** - Uses every confirmed document as a model memory reference.
If a specific field in your documents is **consistently producing inaccurate results**, you can improve performance by adding a **field prompt**.
A field prompt allows you to give the model **additional instructions** for extracting that field.
**Example: Customer Address**
> *Extract this information from where it is EXPLICITLY stated in the invoice document (e.g. "car stored at"), rather than the address of the person the invoice is addressed to. Do NOT confuse with the address of the supplier. It is better to keep this blank than return an incorrect address.*
A practical guide to writing effective field descriptions, with eight patterns for fixing common extraction mistakes.
If you are finding that the model is not reading some text on your documents, your OCR settings might not be correct.
Navigate to Workspace Workflow Settings → "Configure Pre-processing" and check your OCR settings are set to "Partial" or 'Always Full" to avoid missed text.
### Troubleshooting low-performing documents
Go to your document, and click the three dots in the top right corner.
Click "Model Memory Reference".
Review the fields on the Model Memory reference. Incorrect extraction on this document could be responsible for incorrect predictions. Make corrections as needed.
If a high‑volume document template isn’t performing as expected, upload a representative example to Model Memory to boost accuracy.
To do this, upload your example document, validate the extracted data, and click 'Confirm'.
Reparse existing documents and check that they are referencing the correct similar example document.
The Model Memory settings found in Workflow settings determine which documents are automatically added once a document is confirmed. However, Organization Admins retain the ability to add or remove documents from Model Memory independent to further control and improve model performance.
Documents can be added or removed from Model Memory though the Document List view within a Workspace. This can be applied to a single document, or as a bulk action.
# Creating a new model
Source: https://docs.affinda.com/handbook/model-creation
Step-by-step guide to creating and configuring a new Affinda Information Extraction model in minutes, including schema setup and training data.
## Purpose
This guide provides step-by-step guidance for new users of the Affinda platform to create a new information extraction model. By following these steps, users will have a performant model for any document type that they wish to process in just minutes.
This tutorial is for new users of the Affinda Platform looking to get started with document automation. To follow this tutorial, Users should hold Organization Owner or Admin permissions.
## Step-by-Step
Visual Learner? Follow along with our Video Tutorial:
When you first create a Workspace, you will be prompted to upload your first document(s).
To add a new Document Type to an existing Workspace, first upload an example document.
After uploading, you will be prompted to select '+ New Document Type'.
If a Document Type has already been added to your Workspace, the classification model may automatically classify the document. To override this, click the dropdown next to the Document Type (above the list of fields in the right-side panel) and select 'Remove Classification'.
You can then proceed to add a new document type.
Our AI model will interpret the contents of your document and determine what type of document it is.
Our models will suggest a **name** for your document type. This will be used by the model for classification, so adjust it to accurately reflect your documents.
Users can then describe the fields to extract. This can be list of the exact fields needed, or a broader overview of the types and categories of information needed. The Affinda Platform will interpret the meaning of the description and set the fields up accordingly.
Once the initial fields have been set up, you will move to the Document Type Configuration View.
Here, you can make add, delete or update fields to get to the exact configuration needed for your use case.
* **Deleting Fields** – To delete a field, select the red bin icon.
* **Adding New Fields** – Users can add fields from the bottom right-hand corner or by selecting the + icon next to a field heading. This will open the Edit Field view, where you can name your field, select the data type, and configure advanced settings. Once you name your new field, the model will predict it on your document.
* **Editing Fields** – Users can modify a field's label, data type, or other settings as needed by clicking the pencil icon to open the Edit Field view.
* **Organise your Fields** – Create relevant headings and drag and drop to move your fields between headings.
See the Advanced configuration guide to explore advanced options.
Once happy with your configuration, click 'Finish Configuration'.
Now you have successfully created a new document type and extraction model.
Users are now in the Document Validation interface, where the extracted data should be reviewed for accuracy. When the data is correct, users can click 'Confirm Document' and the document will be added to Model memory to improve performance.
## 4. Additional Resources
See the [User Validation Tutorial](/academy/review-extraction) for more information on validating data and the[ Improving Accuracy Guide](/academy/improving-accuracy) for strategies to uplift the performance of your models if required.
Should you need to delete a Document Type, navigate to Document Type > Settings.
# Setting up and managing Affinda in production
Source: https://docs.affinda.com/handbook/production-best-practices
Recommended workspace architecture and change management practices for teams moving from build to production on the Affinda platform.
## Purpose
This guide covers the recommended setup for teams moving from build to production on the Affinda platform - how to structure workspaces, manage [model memory](/configuration/model-memory), and handle changes safely without disrupting live processing.
These are recommendations, not hard requirements. Adapt the structure to fit your team size, governance model, and rollout cadence.
## Recommended workspace structure
We recommend separating your organization into three workspaces, each with a clear purpose. Keeping them separate makes it easy to control access, isolate change, and keep production predictable.
The source of truth for what the model has learned. All [model memory](/configuration/model-memory) documents live here.
* All confirmed model memory documents stored here
* Annotations updated here when fields or behavior change
* New document variations added here first
* Access restricted to configuration owners
A staging environment for validating changes before they reach production. Also used for UAT.
* Document types configured in Training are linked here
* Integration testing space
* No independent model memory; inherits the Model memory that lives in Train config
* Safe to experiment and break things here
Live document processing only. No training activity happens here.
* Model memory toggle turned off
* Document types promoted here only after testing
* All documents processed via API from here
* No direct schema edits — go through Training first
**Access control:** keeping workspaces separate lets you control who sees what. Only configuration owners need access to Training. Your operations team works in Production. Dev/Test is for internal QA and integration testing.
Use **"Duplicate Document type"** to easily set up Test and Production workspaces from your Training workspace.
## Making changes whilst in production
Once your workflow is live in production, you may still need to update your document types or workflow settings from time to time. Identify the type of change you want to make, then follow the recommended approach below.
### Scenario A — New document variation
The model is seeing a new version or variation of a document type already set up in the platform. It may not be performing well due to no closely matching example in the models model memory set.
**Approach:** Add to model memory → Training workspace
Upload the new variation to the Training workspace.
Annotate all fields correctly and confirm the document as model memory.
Performance improves in production automatically — no deployment step required.
Adding a new variation to a model's Model Memory can be done safely without pausing production. Only newly processed documents that are more similar to the new variation than others in your model memory set will be impacted.
### Scenario B — Small schema change
Adding or tweaking one or two simple fields.
**Approach:** Edit in place → Training
Edit the schema directly in the Training workspace.
Re-predict the new or changed field on the model memory document, then reconfirm it.
Changes take effect in production straight away.
**Check first:** confirm that the change won't break or affect any downstream integrations before proceeding.
### Scenario C — Significant schema change
Groups, nesting, structural changes, or anything that requires integration retesting.
**Approach:** Duplicate → Dev/Test → Production
Leave the existing production document type in place while you build the new version.
Duplicate the document type in Training and make all changes on the new duplicate.
Re-upload, re-annotate, and confirm all model memory documents on the new duplicate.
Link the duplicate to the Dev/Test workspace to test the integration flow and make adjustments.
Validate the full API payload end-to-end against the new schema.
Once sign-off is complete, unlink the old version from production and link the new one.
# User validation of extracted data
Source: https://docs.affinda.com/handbook/review-extraction
Validate extracted data in the Affinda review interface to correct values, improve model accuracy over time, and approve documents for downstream export.
## Purpose
The Affinda platform automates the extraction of data from your documents into a structured and usable format. However, user review may be required to validate the model outputs. This tutorial will guide you through validating the data extracted from your documents in the Affinda Platform.
If you're a new user of the Affinda platform, we recommend viewing the [Getting Started with the Affinda Platform](/academy/getting-started) tutorial first to get familiar with our app.
This tutorial is aimed at users who are reviewing the outputs from the Affinda platform. This may be for:
1. **Model improvement:** Confirming documents when the data is correct will improve model performance over time by adding the documents to 'model memory'
2. **Ongoing document processing:** 'Human in the loop' review of documents processed as part of general processes
We recommend reading the [Getting Started](/academy/getting-started) tutorial to understand some core components of the Affinda Platform before completing this tutorial.
## Step-by-Step
Visual Learner? Follow along with our Video Tutorial:
Start by opening the Document Validation Interface for a document you want to review.
The validation interface provides an easy and intuitive interface to validate the data extracted from your documents.
1. The left-hand pane shows the list of documents for review. You can navigate between documents by clicking on their name,
2. The status of the document is shown in the top pane above the document. For Validation, you should look at documents with "For Review" status. Documents that have already been reviewed will have "Confirmed" status.
3. The document is displayed in the middle of the interface.
4. The right-hand pane shows your fields and the value the model extracted from the document you have open.
5. In the bottom right corner, you can see if any validation rules have failed on this document. If you hover your mouse over, you can see exactly which rules have passed and failed.
6. At the bottom right corner is the "Confirm document" button. Confirming the document allows the model to learn and improve accuracy. However, only confirm a document once all extraction has been checked and corrected, to avoid the replication of errors.
* **Orange fields** show the model's predictions for that field on the document; they should be reviewed.
* **Red fields** indicate the data extracted from the document failed a validation rule; these should be checked.
* **Green fields** have been confirmed. The tick symbol indicates the field was manually confirmed, whilst the lightning bolt icon indicates the field was auto-confirmed as it passed validation rules.
Check each field and validate that the data extracted by the model matches what's on the document.
Always check for fields that failed validation rules, and for any key fields that might be missing.
If you notice a field has been missed or extracted in the wrong place, correct the annotation by adjusting or redrawing the box on the document where it should've been extracted. Make sure you have selected the correct field name in the drop-down, and press confirm.
### Fields with multiple annotations
If the data for a single instance of a field requires multiple annotation boxes (e.g. the field crosses across page boundaries), you can create multiple rectanges.
* Draw the first box.
* Click the **+** icon on the right-hand side of the box.
* Draw another rectangle.
The text from all rectangles will be combined into a single field.
Repeat this process for all incorrect fields on your document.
Once you are happy with all the fields and their extracted values match what's on the document, click **"Confirm Document"**.
Depending on your **Validation Settings**, you might not be able to confirm a document until all of your validation rules pass.
Once the document is corrected and confirmed, the model can use it in its **Model Memory**. This allows the models to learn from your documents and improve performance on future documents.
Clicking confirm will move you on to the next document in the "For Review" queue.
## Additional actions
Other helpful features in the validation interface include:
1. **Reclassification:** Adjust or remove the document's classification, which triggers the document to re-parse. See [Splitting & Classification tutorial](/academy/split-classify) for more information.
2. **Edit Pages:** Split documents into multiple files, rotate pages, or delete pages as needed. See [Splitting & Classification tutorial](/academy/split-classify) for more information.
3. **Apply OCR:** Apply Optical Character Recognition (OCR) to address text extraction issues and automatically reprocess the document.
4. **Model Memory Reference:** Review the reference document used by the model for extraction. Useful for checking if a similar document format is already stored in Model Memory and identifying any annotation errors.
5. **Re-parse:** Re-process the document using the latest model updates.
# Schema design and field configuration best practices
Source: https://docs.affinda.com/handbook/schema-design
Practical guidance for designing document schemas and configuring fields in Affinda to maximize extraction accuracy and downstream integration quality.
## Overview
When setting up document extraction in Affinda, one of the most important decisions you’ll make is how to configure your **schema.**
Your schema is the set of fields the system extracts and returns for each document. It refers to not only the list of fields, but also their structure and the formatting applied.
This guide explains how to think about field configuration, what trade-offs to consider, and how to use advanced options carefully.
## Why Schema Design Matters
The schema is more than just a list of fields. It determines:
* What data will the model try to extract
* How easy it is for your team to review and correct that data
* How cleanly the extracted data can be passed into your other systems
A poorly designed schema can lead to confusing user experiences, low accuracy, or messy downstream integrations. A well-designed one avoids all that.
## What to Consider When Designing Your Schema
Here are the key trade-offs to consider when deciding what fields to include, and how to configure them.
Not every piece of data needs to come from the document.
* Some fields might be optional or easier to fill in later.
* If a field is *nice to have* but not essential, consider leaving it out.
* Prioritize fields that are **critical**, **hard to get elsewhere**, or **needed to trigger automation**.
Some field types are harder for the AI to extract accurately—especially complex, nested, or grouped fields.
* **Simple fields = better accuracy**
* **Every field adds risk**: If the model struggles with a field, it may make errors—even if the rest of the document is simple.
* **More fields = more training needed**: If you want to improve accuracy for complex fields, it may require a custom model or more training data.
Your team (or users) will often review documents and confirm or edit extracted data. The easier this is, the faster the process.
* **Simpler is better**: Flat schemas with clear field names are easier to check.
* **Avoid overcomplication**: Deeply nested fields or grouped data can slow reviewers down and increase mistakes.
Think about how you plan to use the extracted data.
* Is your downstream system expecting a specific format?
* Will someone need to clean or restructure the data before using it?
If your schema aligns with your downstream format, you’ll avoid a lot of post-processing work.
## Higher complexity field options
The simplest, and most common, field type is a single, flat value (like text, number, or date) from a clearly defined location on the document. They’re the easiest for the model to extract accurately and review in the UI.
Below, we'll walk through when some more advanced field configuration options could be used and the potential downside that needs to be managed when introduced. These options are powerful—but should be used with care.
For information on how to configure these settings, see our [Configuration Guide](/configuration/field-configuration).
Enable this if a field may appear multiple times with distinct values (e.g. multiple invoice numbers). You do not need to enable this if a field appears multiple times with the same value (e.g. Customer name)
**Use only when needed:**
* Extracting multiple values makes things harder for the model.
* It also increases the risk of messy integrations (e.g. when downstream systems expect a single value).
* Can confuse users reviewing the data.
**Tip:** If most documents only have one value, leave this off.
You can apply basic formatting (like trimming text, formatting dates, or converting currency symbols) to extracted values.
**Pros:**
* Helps the data match what your system expects
* Can reduce post-processing effort
**Cons:**
* Adds complexity to your setup
* Can hide problems with the raw extraction
* May behave unexpectedly with unusual documents
**Tip:** Only transform text when you’re sure of the format you need. Keep it simple.
Use groups to extract sets of related data (e.g. line items in a table).
**But be careful:**
* Groups are tricky for the model—especially if the document doesn’t visually show a clear grouping.
* When groups span across pages, the complexity increases.
* Often need custom configuration to get it right.
**Recommendation:** If you need group fields, [get in touch with Affinda’s team](https://www.affinda.com/contact)—we’ll help you set them up properly.
These are fields where the model does **not** try to extract visible text directly from the document—meaning it won’t draw a box (rectangle) around any raw text.
Instead, the model infers the value based on other content in the document.
**When to use:**
* You want the model to **reason or summarize** (e.g. determine payslip frequency from date ranges)
* The value isn’t written explicitly anywhere in the document
* You care more about **interpretation** than locating specific text
**Benefits:**
* Let's you extract insights or summaries, not just literal text
* Enables smarter use cases that go beyond raw OCR
**Drawbacks:**
* Accuracy is harder to validate—since there’s no reference text to compare against
* Performance depends heavily on how well the field is described
* Harder to troubleshoot or improve if predictions are wrong
**Best practice:** Write a clear, descriptive field label and description so the model understands exactly what you’re asking it to do. Ambiguous instructions lead to poor results. See [Writing Field Descriptions](/handbook/field-descriptions) for practical patterns.
These are fields that aren't predicted by the model. Often used in combination with 'rectangle-less fields to allow users to specify data not present in the document (e.g. comments, internal codes).
**Good for:**
* One-off user notes or tags
* Fields that aren’t extractable but still needed
**Don’t overuse:**
* Too many manual fields turn your extraction tool into a data-entry form.
* Better to do heavy manual entry in your destination system, and keep Affinda focused on what’s in the document.
**Best practice**: Limit manual fields to 1–2 max per schema.
## Final Tips for Success
* **Start simple**: Begin with just the essential fields. Add more later if needed.
* **Review early**: Test with real documents and see how the data looks.
* **Trim the fat**: Remove unused or low-accuracy fields.
* **Talk to us**: Affinda can help guide your configuration for optimal results.
## Need Help?
If you’re unsure how to configure a field, want advice on best practices, or are working with complex document types, our team is here to help. [Reach out any time.](https://www.affinda.com/contact)
# Integration workflows and solution design patterns
Source: https://docs.affinda.com/handbook/solution-design
Compare integration workflow patterns for connecting Affinda to your existing document processing pipelines, including API, email, and ATS integrations.
## Purpose
The Affinda Platform is designed to flexibly integrate into a wide range of document processing workflows. We understand that every customer’s internal systems, validation rules, and exception handling processes are different.
This guide outlines a framework to help you choose the most suitable integration workflow that fits your use case. It presents six common integration patterns used by customers today, each representing a distinct way to manage the flow of documents, data, and decisions between your system and Affinda.
The workflows presented cover some of the common setups in production, but they are not intended to be exhaustive. Depending on the use case, customers may need to adapt or extend them. For additional details, check out the FAQs at the bottom of this article or book a quick consult.
## Workflow criteria
Your solution design will heavily depend on the answer to two key questions.
### Q1. Will any exceptions be reviewed in Affinda’s UI?
Exception handling requires users to review any documents that fail validation logic and manage the steps needed to correct them. This may occur within Affinda via our validation interface, or entirely within your system using custom workflows or user interfaces.
### Q2. Will any validation or mapping logic be completed inside Affinda?
Validation logic refers to the business rules used to decide whether the extracted data is complete, correct, or acceptable. This could be implemented by:
* Implementing within the Affinda Platform using our validation rule and data mapping capabilities (see our tutorial on [Straight-Through Processing](/academy/straight-through-processing) for more information)
* By implementing this logic in your system
In cases where rules are applied in your system, the results of these validation checks can be sent back into the Affinda Platform for the exception handling process.
“Rules” refers to any logic that auto-confirms fields or raises warnings where requirements are not met (e.g., supplier match exists, totals match).
## Workflow Summary Table
| ID | Workflow name | Q1. Exceptions | Q2. Validation | Explanation |
| :----- | :-------------------------------------------------------- | -------------- | --------------------------- | :-------------------------------------------------------------------------- |
| **W1** | No validation | No | No | Upload → get JSON. No rules, no human in the loop. |
| **W2** | Client-side validation | No | No | Same as W1, however, customer applies rules once data has been exported. |
| **W3** | Affinda validation logic | No | Yes - rules live in Affinda | Affinda validates automatically; no human review. |
| **W4** | Review all documents in Affinda | Yes | No | Humans review every doc in Affinda UI; no automated rules. |
| **W5** | Client-side validation with exception handling in Affinda | Yes | Yes - rules owned by client | Your rules, pushed back as warnings; flagged docs reviewed in Affinda. |
| **W6** | Validation logic & exception handling in Affinda | Yes | Yes - rules live in Affinda | Affinda validates; flagged docs reviewed in Affinda for final confirmation. |
In some cases, the validation interface can be embedded within a client's system to assist with exception handling. See [Embedded Mode](/reference/embedded) to learn more, or discuss with Affinda to learn how to enable this.
## Detailed overview
The below provides detailed explanations of each of the workflow options.
Unless explicitly stated, all workflows assume that webhooks are used to notify your system when a document is ready for the next step. If webhooks aren’t feasible in your environment, synchronous polling or scheduled checks can be used as alternatives but may introduce latency or additional complexity.
This is the simplest workflow: documents are uploaded, parsed, and data is retrieved as-is with no further validation or review. It’s ideal when the extracted fields are either low-risk or used only as a starting point for downstream systems. It offers the fastest turnaround and minimal integration effort.
### API integration
1. `POST /document`
2. `webhook: document.parse.completed`
3. `GET /document`
Follows the same workflow and integration with Affinda as W-1, however, validation rules and/or user review occurs in the client system after the data has been exported. These rules and user review does not get sent back to Affinda.
### API integration
1. `POST /document`
2. `webhook: document.parse.completed`
3. `GET /document`
Here, Affinda handles parsing and validation, but all exception handling takes place in your system. Documents that fail your rules are flagged for manual review in your own user interface or workflow engine. This gives you complete control over the review experience while still leveraging Affinda’s validation logic. It’s a good fit for teams that already have internal exception queues or don't want users to manage multiple platforms.
### API integration
1. `POST /document`
2. `webhook: document.validate.completed`
3. `GET /document`
* Use `GET /allvalidationresults` to get results for each field, else use `isConfirmed` from the document response to determine if the document needs exception handling
In this workflow, all documents are validated by a user within Affinda. This is a good fit for customers who want all documents to undergo some form of user validation. It can often be used as an intermediary step to validate the accuracy of the data before enabling straight-through processing of documents without any user intervention.
### API integration
1. `POST /document`
2. `webhook: document.validate.completed`
3. `GET /document`
In this pattern, Affinda performs the initial extraction, and the data is sent to the customer’s system. Validation occurs within the client’s system and any documents failing validation logic are then reviewed by users within Affinda.
This is well-suited for teams that want to keep humans in the loop using Affinda's validation interface, but want to use their own systems to run validation logic across documents. This may be because either:
* Validation logic is already built and do not want to move this across into the Affinda Platform
* Have a high amount of reference data needed for validation
* They prefer not to build their own correction interface
It’s a good balance between automation and control, especially for medium-volume workflows with variable document quality.
### Updating results in Affinda
The two most common ways to send failed validation results created in your system are:
1. **Field validation results:** Add field-level warnings explaining why they have failed validation.
2. **Warnings:** Add a document-level message explaining which fields need attention (see image below).
Documents that have passed all validation results and do not need any exception handling ior user validation should be updated so that their status is set to 'Confirmed.
### API integration
1. `POST /document`
2. `webhook: document.parse.completed`
3. `GET /document`
4. `PATCH / document (`add `warningMessages`) or `POST /validation-results/batch-create-validation-results` (see 'Updating results in Affinda' above)
5. `webhook: document.validate.completed`
6. `GET /document`
7. `PATCH /document` (`isConfirmed` set to true)
This fully automated workflow waits until a document is 'confirmed' within Affinda (either automatically or via user review), then triggers a webhook for your system to collect the final data.
It requires no intervention or mid-process interaction from an integration perspective, making it ideal for high-volume pipelines.
### API integration
1. `POST /document`
2. `webhook: document.validate.completed`
3. `GET /document`
## External reference data
### Global data
Many teams will have a master list of data that they want to map the extracted data to - this is known as a [Data Source](/configuration/picklists) in Affinda. This reference data can be added by uploading a flat-file via the platform, or by adding and updating via API. This global reference data is managed separately from the document upload and export flow, and the matching of raw data to reference data occurs within the document processing.
### Document specific data
Occasionally, teams will need to inject data per document. This may be needed where additional data specific to that document (but not present on the document itself) is needed for validation (e.g., the user submitting the file to the client system specifies the expected value of the document, and this is matched against the extracted data).
In this case, customers should patch the data to the document as part of either W3 or W6.
## FAQs
Data mapping is independent of the chosen workflow. You’ll still need to align Affinda’s extracted field names and values to your internal data model (e.g. supplier lists or GL codes) regardless of how you manage validation or exceptions.
Yes, if you patch fields after parsing, you must explicitly trigger rule re-evaluation to get updated validation results. Skipping this step may cause documents to remain unconfirmed or reflect outdated logic.
Technically yes. Some systems route documents differently based on type, volume, or confidence thresholds. However, maintaining multiple flows increases complexity and should be considered only when the benefit clearly outweighs the overhead.
# Reviewing splitting and classification results
Source: https://docs.affinda.com/handbook/split-classify
Review, adjust, and confirm Affinda's automatic document splitting and classification output before extraction runs on each individual document.
## Purpose
The Affinda platform automates the splitting and classification of documents. However, user review may be required to validate the model outputs. This tutorial will walk you through how to validate the splitting and classification of your documents in the Affinda Platform.
If you're a new user of the Affinda platform, we recommend viewing the [Getting Started with the Affinda Platform](/academy/getting-started) tutorial first to get familiar with our app.
This tutorial is aimed at any users who are reviewing the outputs from the Affinda platform. This may be for:
1. **Model improvement:** Confirming documents when the data is correct will improve model performance over time by adding the documents to 'model memory'
2. **Ongoing document processing:** 'Human in the loop' review of documents processed as part of general processes
## Definitions
Firstly, let's get across what splitting and classification mean in your automated document workflow.
Splitting in Affinda refers to the platform's ability to identify individual documents in a multi-document file. Our models will split these into individual files. This allows them to be classified and sent to the correct extraction model.
Classification is Affinda's ability to identify what type of document it has received. This is beneficial in two ways:
* It gives you visibility on the type of documents you've received
* It allows these documents to be sent to the correct workflow and extraction model
## How to validate document splitting and classification
Start by opening the Document Validation Interface for a document you want to review.
You can see if your document has been split by the Affinda model in the document validation interface. Splitting is indicated by
1. The purple scissors icon will appear next to the document's name on the right-hand panel
2. The "Edit Pages" button in the top right corner will be blue.
**If your document has not had splitting applied (and does not need to be split), skip this step.**
To view the splitting, open the splitting interface by clicking the "Edit Pages" button (2).
Here you can see the full file that was received. You can preview each page to get a closer look.
**To create a new split**: click in between the pages that you want to split.
**To remove a split:** click the "Remove Split" button and merge the documents.
You can also **delete unwanted pages** using the bin icon or **rotate misoriented pages** in this view.
Once you are happy with the changes you have made, click **"Apply Changes"**.
Changing the splitting will trigger the relevant documents to be reparsed to refresh the extraction.
**In Edit Pages Interface:**
If you are already checking the splitting of documents, you can also check the classification in the Splitting Interface. You can see how the model has classified each document by the label next to the document's filename. Change the classification by using the drop-down menu. Make sure you click "Apply Changes" to save changes.
**In Document Validation Interface:**
If you are checking individual documents in the Document Validation Interface, you can see the classification the model has predicted in the top right corner. You can change the classification by using the drop-down menu.
Changing the classification of a document will reparse it as it gets sent to the correct model for extraction.
**For Admins:** If the appropriate classification isn’t available in your Workspace, select **‘Remove Classification’**. This will allow Admins to either create a new Document Type or add an existing one to the Workspace and apply it.
# Achieving straight-through processing
Source: https://docs.affinda.com/handbook/straight-through-processing
Configure machine validation, confidence thresholds, and automation rules to achieve straight-through processing for high-volume document workflows.
## Purpose
This tutorial guides users on how they can achieve full document automation with straight-through-processing in Affinda. Stacking validation rules, data mapping, and correctly configuring your validation settings in Affinda allows documents to pass through without the need for human intervention.
This guide is designed for advanced users in Affinda looking to achieve straight-through processing. To complete this guide, Users should already have their Document Type(s) configured and hold an Owner or Admin role in Affinda.
## What is straight-through processing?
Straight-through-processing in the context of Affinda refers to a fully automated, end-to-end workflow in which documents that enter the system can be:
* Parsed and classified
* Key data fields extracted and validated
* Enriched or transformed as needed
All without the need for human intervention at any stage.
## Straight-through processing in Affinda
Straight-through processing allows documents to be automatically processed without manual intervention. This can be achieved in Affinda by using three features together:
1. **Data Mapping:** To specify how extracted data should be formatted
2. **Validation Rules:** To define what makes a document valid or invalid
3. **Validation Settings:** To control how documents are processed based on their validation status
When these features are properly configured, valid documents that meet all rules will automatically pass through to your downstream systems, while documents that fail validation will be flagged for manual review. This ensures accuracy while reducing unnecessary manual checks, helping your organization work more efficiently.
## Data Mapping
Data mapping is a powerful capability that enhances the accuracy of data extraction. With data mapping configured, the extracted data from a document can be mapped against a list of known options from your knowledge base to validate that it meets expected values. This enables correct values to bypass review, whilst only incorrect values are flagged.
Data Source mapping can be configured through the Affinda app or the API. To configure in the App:
First, start by creating your Data Source field. Navigate to the Configure document type menu, and create a new field with data type "Data Source".
Data Sources act as \*\*lightweight master-data tables \*\*that you can manage from within Affinda.
Select "+ New Data Source" and upload your data source file. Affinda supports CSV, XLSX, or JSON files as data sources.
Or create via **API**:
```http theme={null}
POST /data-sources # Create
```
A *key column* is the single field in your source table whose values are guaranteed to be unique; it is used by Affinda to reliably identify each record unambiguously.
The *label* is the human-readable name stored for each record in a Mapping Data Source; it’s what users will see in the validation UI and drop-downs.
You can manage your Data Sources at the organizational level.
Select the document field to match eg. Employer Name.
Pick the data source property (the column you want to match it to)
Select the match type:
* Exact - strings must be identical.
* Partial - succeeds when the extracted string appears anywhere in the candidate.
* Fuzzy - uses edit-distance logic to allow minor typos to still be matched.
Tick "Required" if validation should fail when nothing matches for this criterion. Enabling this will flag documents that have failed the matching criteria against your data source, flagging them for review. Documents that have passed the matching criteria won't be flagged and can continue to your downstream workflows with the confidence that their fields were extracted correctly.
Ensure your data source is always up to date to maximise documents that can be STP.
You can update data sources manually or automate it with API calls from your integration.
Call `PUT /data-sources/{id}` for full replacement or `PATCH /data-sources/{id}`for incremental updates.
### Tips for reliable matching
* Trim whitespace and normalise case in your source files.
* Ensure the key column is unique.
* Keep label strings short so they fit comfortably in the UI.
## Validation rules
Within the Affinda platform, validation rules can be configured to automatically check whether extracted data meets predefined business logic. When these rules pass, the data is considered valid and does not require user review, enabling straight-through processing for compliant documents. Validation rules help identify documents that fail to meet business rules, prompting review.
Navigate to the Document Type Configuration interface of the document type that contains the field you want to apply a text transformation to.
Click the pencil icon next to the field of your choice to open up the Field Settings.
Open the "Validation Rule" drop-down.
Or go to the validation tab, and click "Add Validation Rule".
Validation rules can be created on just one or multiple extracted fields. Type "@fieldname" to reference a field. Write the rule in natural language and press generate to apply.
**Some example validation rules you might use for inspiration are:**
* "Check @SupplierVAT is a valid VAT"
* "Check @CustomerAddress has a valid postcode"
* "Check the sum of the @subtotals = @totalamount"
* "@purchaseorder is 7 digits long"
You can also include the pass or fail messages you want to be returned in the Validation Interface (e.g. “Ensure the invoice date is before the due date. If not, show: ‘Due date cannot be earlier than invoice date.").
In the advanced settings of your validation rule, you can configure how the rule should act in the case of missing data.
**Available Options:**
* **Skip** -The rule is skipped entirely—no pass or fail outcome is recorded.
* **Fail** - The rule automatically fails if any required field is missing.
* **Pass** - The rule is marked as passed, regardless of missing fields.
* **Ignore** - The rule runs by treating missing fields as neutral, attempting to return a valid result based on available data.
* For example, useful in cases like subtotal + freight + tax = total, where freight is occasionally absent.
You can see how your document performs against your new validation rule and make changes accordingly.
You can also click 'View Code' to see the code generated for the rule.
It's best to check your validation rules across different documents to ensure they perform as desired. Test both documents that should pass and fail the rule.
The easiest way to manage validation rules is in the Validation tab in the Document Type Configuration Interface. There, you can disable fields when needed.
## Validation Settings
Once you have your data mapping and validation rules configured, the last step to enable straight-through processing is to enable **auto-confirmation**. This allows Affinda to confirm documents that have passed all data mapping and validation rules, sending them downstream automatically without human review. Documents that fail data mapping or validation rules will be flagged and left for human review.
You can enable auto-confirmation in the **Validation Settings** within your **Workflow Settings**.
If 'Auto-Confirmation' is enabled, a document will skip the 'For Review' queue if there are no failed rules on that document (and at least one rule is enabled). It ***does not*** require each individual field to be auto-confirmed for the document to be auto-confirmed.
## User Validation
Documents that aren't correct or don't pass business rules will need to be reviewed. Affinda's Document Validation interface offers a user-friendly platform to review and manage these documents. Setting up straight-through processing ensures these documents are flagged for easy review. To learn how to review documents, see our [Tutorial: Review Extraction. ](/configuration/user-validation)
# Edit extracted tables in the table editor
Source: https://docs.affinda.com/handbook/table-editor
Use the Affinda table editor to add, remove, and correct rows and columns in extracted tables before approving documents for downstream export.
## Purpose
Extracting data from tables can be slow and error-prone. Affinda’s table editor makes this process fast and reliable by letting you validate and correct tables using two editing modes: **Grid** (for clean, column-based tables) and **Freeform** (for irregular or nested layouts).
This tutorial explains how to review and adjust tables extracted by Affinda — whether you are:
* **Improving model performance** by confirming correctly extracted tables (adding them to model memory), or
* Reviewing documents as part of **ongoing processing workflows**.
## Grid vs Freeform
Affinda automatically selects a table mode when a table is detected or drawn, but you can switch at any time using the **Grid / Freeform toggle** at the top of the editor.
### **Grid**
Use **Grid** for classic, well-structured tables where data falls neatly into rows and columns.
* Best for: invoices, order lines, financial tables, spreadsheets
* You adjust **row lines** and **column lines** directly on the document
* The table output updates **immediately** as you move lines — *no Fill down used in Grid mode*
### **Freeform**
Use **Freeform** when the table cannot be cleanly separated by vertical columns — for example, when fields are stacked (e.g. a code on one line and a description beneath it).
* Best for: irregular layouts, nested blocks, multi-line item structures
* You annotate **one complete example row**
* Then apply **Fill down** to propagate that row’s logic to all remaining rows
## Step-by-Step
In most cases, Affinda will automatically predict a table that exists in the document.\
If not — or if you delete the prediction — draw a box around the table area (excluding the header) and select the correct table field.
Affinda will immediately detect rows and prefill values based on the table type.
Click the table boundary and drag to adjust it if needed.\
This ensures all rows and fields are included before you begin refining the table.
The boundary can be adjusted in both Grid and Freeform modes.
Rows are edited the same way in **both** Grid and Freeform modes.
**Adjusting row lines**
Drag the horizontal row lines up or down so each row contains exactly one line item.
**Add / remove rows**
* Hover on the **left side** of the table to add a new row (a **+** button appears)
* Click the **✕** next to a row to delete it
**Tick / Untick**
Tick marks on the left control whether a row is included in the table output.
* **Ticked** rows → included
* **Unticked** rows → ignored
In Grid mode, drag **vertical column lines** at the top of the table to match the document’s structure.
Once the columns are aligned:
* Click the **column header dropdown**
* Select the correct field (e.g. Description, Quantity, PO Number, Total)
The table output updates instantly as you adjust the grid — no Fill down is needed in Grid mode.
In Freeform mode, annotate a **single complete example row** by drawing boxes around each field exactly as it appears (e.g. a stacked “CT number + description” pair).
When the first row looks correct:
* Click **Fill down** to apply its structure to the remaining rows
* If for some instance Fill down doesn’t work correctly for a later row, correct that row manually and apply Fill down again from that row downward
### Tip: Set rows correctly before filling down
Fill down relies heavily on accurate row boundaries. The cleaner the row structure, the better the propagation.
Most tables will be correct after the first Fill down or first Grid adjustment.
If not:
* Fix the next incorrect row
* In Freeform mode, apply Fill down again from that row
* Continue until all rows look accurate
This top-to-bottom workflow gives the best results.
# Affinda documentation: document AI platform guides and API
Source: https://docs.affinda.com/home
Guides, tutorials, and API reference for the Affinda document AI platform, covering extraction models, validation, integrations, and best practices.
AI agents can read the complete Affinda platform reference in a single file at [docs.affinda.com/skill.md](https://docs.affinda.com/skill.md).
Want to see Affinda in action? Start a [free trial](https://app.affinda.com) or [book a demo](https://www.affinda.com/contact).
## Foundational Tutorials
Learn the basics of navigating the Affinda platform.
Learn how to create an accurate model for your document type in just minutes.
Strategies to increase model accuracy above 99%.
## User Validation 101
Detailed guide to confirming extracted data in the validation interface.
Step-by-step guidance on extracting data from simple to complex tables.
How to adjust model predictions for document splits and classification.
## Advanced Configuration Playbooks
Suggested workflows based on your requirements.
Learn how to export structured data to any downstream system using the Affinda Agent.
Configuring the Affinda platform to reduce the amount of user intervention required.
Best practices for configuring you field structure to optimise performance.
### Explore other Resources
Comprehensive guidance on how to configure document automation with Affinda.
Integrate with your systems using Affinda's REST API, Client Libraries and other developer tools.
Information specific to users looking to use Affinda's Resume Parser and complementary products.
Keep up to date with product developments, ease any security concerns, and answer any other questions you have.
# Affinda MCP connector and AI agent plugin
Source: https://docs.affinda.com/integrations/mcp-connector
Connect Claude, Cursor, Codex, and other MCP-aware AI clients to Affinda's hosted MCP server to configure workspaces and run document extraction workflows.
The Affinda MCP connector exposes the full Affinda platform as a set of tools that any [Model Context Protocol](https://modelcontextprotocol.io)-aware AI client can call — Claude Desktop, Claude Code, Cursor, Codex, or your own code via the Anthropic API. Once connected, your AI assistant can create workspaces, configure document types, upload documents, retrieve extracted data, and manage the entire processing lifecycle, all by natural language.
The easiest way to add it is the **Affinda plugin** (from [github.com/affinda/skills](https://github.com/affinda/skills)), which bundles the connector together with a structured skill that teaches the agent how to sequence the tools into real-world workflows. You can also add just the connector if you only want the tools — both are covered below.
Add the Affinda plugin (connector + skill) in Claude Desktop, Claude Code or Codex — or just the connector in Cursor and the API.
What the bundled skill adds, the regional plugins, and manual install for managed accounts.
Set up invoice and resume extractors, debug low-confidence results, and manage document review queues.
Region endpoints, supported document types, and authentication FAQ.
## What you can do
With the Affinda MCP connector connected your AI client can:
* **Create and configure workspaces** — set up OCR modes, splitting, classification, and model memory.
* **Design extraction schemas** — create document types, add fields (text, date, number, table), and attach validation rules.
* **Upload and process documents** — submit files by URL or path and poll until extraction is complete.
* **Read extracted data** — retrieve per-field values and confidence scores for any processed document.
* **Run a human review queue** — list documents awaiting review, inspect extractions, and confirm, reject, or archive them in bulk.
* **Connect data sources** — attach lookup tables (approved vendors, cost centres, skill taxonomies) to fields for validation and auto-population.
* **Manage integrations** — configure export endpoints so confirmed documents push structured data to downstream systems.
The server exposes approximately 75 tools across organisations, workspaces, documents, document types, fields, data sources, matching criteria, integrations, and API token management.
***
## Install Affinda in your AI client
The recommended way to add Affinda is the **Affinda plugin**. It bundles the hosted MCP connector together with a structured *skill* — workflow guides and reference material — so your agent knows not just *which* tools exist but *how* to sequence them for real jobs like standing up an invoice extractor or running a review queue. The plugin is available for **Claude Desktop, Claude Code, and Codex**.
For clients without a plugin (**Cursor**, the **Anthropic API**), or if you want only the server without the skill, add the **MCP connector directly** by URL — each tab below shows both.
However you connect, you authenticate via **OAuth 2.1**: your client redirects you to log in with your Affinda account and then holds the access token automatically. There is no manual token handling.
**Pick the endpoint for your region.** Affinda runs three isolated regions and your account lives in exactly one. The rule is simple: your MCP endpoint is the **same address you sign in to Affinda from, with `app.` swapped for `mcp.`**. Connect to the wrong region and you'll sign in fine but see no workspaces — so if you're unsure, log in to Affinda and check your browser's address bar.
| Region | You sign in at | MCP endpoint URL |
| ------------------- | --------------------- | --------------------------------- |
| Australia (AP1) | `app.affinda.com` | `https://mcp.affinda.com/mcp` |
| United States (US1) | `app.us1.affinda.com` | `https://mcp.us1.affinda.com/mcp` |
| Europe (EU1) | `app.eu1.affinda.com` | `https://mcp.eu1.affinda.com/mcp` |
### Install the Affinda plugin in Claude Desktop
Each `.zip` bundles the connector for one region (same `app.` → `mcp.` rule as above):
* Australia (AP1): [affinda-claude-plugin.zip](/downloads/affinda-claude-plugin.zip)
* United States (US1): [affinda-claude-plugin-us1.zip](/downloads/affinda-claude-plugin-us1.zip)
* Europe (EU1): [affinda-claude-plugin-eu1.zip](/downloads/affinda-claude-plugin-eu1.zip)
Open **Customise**, click **+** next to **Personal plugins**, choose **Upload plugin**, and select the file. It must keep its `.zip` extension.
Run `/mcp` (or follow the connector prompt) and sign in with your Affinda account, then start a conversation and type:
> "List my Affinda workspaces."
The assistant should call the `list_workspaces` tool and return the workspaces in your account. If you see an authentication error, repeat the sign-in step.
Open **Settings → Integrations** (or **MCP Servers**), click **Add integration**, and paste the endpoint URL for your region (give it the name `affinda`):
```text Australia (AP1) theme={null}
https://mcp.affinda.com/mcp
```
```text United States (US1) theme={null}
https://mcp.us1.affinda.com/mcp
```
```text Europe (EU1) theme={null}
https://mcp.eu1.affinda.com/mcp
```
Claude Desktop opens a browser to sign in; the tools then appear in the conversation.
### Install the Affinda plugin in Claude Code
From inside a Claude Code session, add the marketplace once, then install the plugin for your region:
```
/plugin marketplace add affinda/skills
```
```text Australia (AP1) theme={null}
/plugin install affinda@affinda-skills
```
```text United States (US1) theme={null}
/plugin install affinda-us1@affinda-skills
```
```text Europe (EU1) theme={null}
/plugin install affinda-eu1@affinda-skills
```
Then run `/mcp`, complete the browser sign-in with your Affinda account, and ask *"List my Affinda workspaces."*
Add only the MCP server (no plugin or skill) with the CLI — use the name and URL for your region:
```bash Australia (AP1) theme={null}
claude mcp add --transport http affinda https://mcp.affinda.com/mcp
```
```bash United States (US1) theme={null}
claude mcp add --transport http affinda-us1 https://mcp.us1.affinda.com/mcp
```
```bash Europe (EU1) theme={null}
claude mcp add --transport http affinda-eu1 https://mcp.eu1.affinda.com/mcp
```
Or add it manually to `~/.claude/settings.json` under `"mcpServers"` (swap the URL for your region's endpoint from the table above). Claude Code prompts you to sign in the first time a tool is called.
### Add the connector in Cursor
Open Cursor settings, navigate to the **MCP** section, and add a new server entry. Alternatively edit `~/.cursor/mcp.json` directly, using the entry for your region:
```json Australia (AP1) theme={null}
{
"mcpServers": {
"affinda": {
"url": "https://mcp.affinda.com/mcp"
}
}
}
```
```json United States (US1) theme={null}
{
"mcpServers": {
"affinda": {
"url": "https://mcp.us1.affinda.com/mcp"
}
}
}
```
```json Europe (EU1) theme={null}
{
"mcpServers": {
"affinda": {
"url": "https://mcp.eu1.affinda.com/mcp"
}
}
}
```
Save and restart Cursor. Cursor prompts you to sign in via OAuth the first time the server connects, after which the Affinda tools appear in the agent panel.
### Install the Affinda plugin in Codex
Codex supports plugins (v0.117.0+), so the simplest path is to install the Affinda plugin — it bundles the connector and the skill, just like the Claude Code plugin.
```bash theme={null}
codex plugin marketplace add affinda/skills
```
Then run `/plugins` in Codex, select the plugin for your region — **Affinda** (AP1), **Affinda US**, or **Affinda EU** — choose **Install**, and sign in with your Affinda account when prompted.
Prefer just the MCP server, without the bundled skill? Add the entry for your region to `~/.codex/config.toml` (or a project-level `.codex/config.toml`) instead:
```toml Australia (AP1) theme={null}
[mcp_servers.affinda]
url = "https://mcp.affinda.com/mcp"
```
```toml United States (US1) theme={null}
[mcp_servers.affinda]
url = "https://mcp.us1.affinda.com/mcp"
```
```toml Europe (EU1) theme={null}
[mcp_servers.affinda]
url = "https://mcp.eu1.affinda.com/mcp"
```
Codex authenticates on first use.
### Use the connector via the Anthropic API
If you are calling the Claude API directly, pass the MCP server as part of your request:
```python theme={null}
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=4096,
messages=[{"role": "user", "content": "List my Affinda workspaces."}],
mcp_servers=[
{
"type": "url",
"name": "affinda",
# Use your region's endpoint — see the Regions table above.
"url": "https://mcp.affinda.com/mcp",
}
],
)
print(response.content)
```
The Anthropic API MCP connector currently supports tool calls only. MCP prompts and static resources (such as `affinda://concepts`) are not surfaced through this path. For full feature coverage use one of the desktop or IDE clients.
***
## About the Affinda plugin
The plugin combines the MCP connector with a structured **skill** — workflow guides and reference material the agent consults when planning multi-step tasks — and is distributed from [github.com/affinda/skills](https://github.com/affinda/skills). Installing it means your agent knows not just *which* tools exist, but *how* to sequence them for common jobs like setting up an invoice extractor or running a review queue. There is a separate plugin per region (`affinda`, `affinda-us1`, `affinda-eu1`); the install tabs above select the right one for you.
Install one regional plugin at a time. Having more than one installed simultaneously exposes duplicate tool sets and makes region selection ambiguous.
The skill is optional. Every tool stands on its own — the skill only adds multi-step workflow guidance on top of the tool descriptions. The "just the MCP server / connector" options in the tabs above give you the tools without it.
### Download and upload the plugin manually
If you can't add a marketplace — for example on a managed account, or if you'd rather not connect GitHub — download the plugin `.zip` for your region and upload it directly. In Claude Desktop, open **Customise → Personal plugins → Upload plugin** and select the file (it must keep its `.zip` extension); then run `/mcp` and sign in with your Affinda account.
* Australia (AP1): [affinda-claude-plugin.zip](/downloads/affinda-claude-plugin.zip)
* United States (US1): [affinda-claude-plugin-us1.zip](/downloads/affinda-claude-plugin-us1.zip)
* Europe (EU1): [affinda-claude-plugin-eu1.zip](/downloads/affinda-claude-plugin-eu1.zip)
***
## Organizations, Teams & Enterprise
On a managed Claude account, governance changes how the plugin and connector get installed. The short version: an **admin** usually has to make the plugin *and* the MCP connector available before members can use them.
Claude's plugin and connector surfaces change often. The paths below were accurate as of May 2026 — check your admin console before rolling out.
Add the `affinda/skills` marketplace and install the plugin (above), or upload the `.zip` directly. You can add the MCP connector yourself via **Customize → Connectors** or `claude mcp add`.
In **Claude Desktop**, organizations can't add public plugin marketplaces. As an Owner / Primary Owner you have two routes:
* **Fork + sync** — fork [github.com/affinda/skills](https://github.com/affinda/skills) into a **private** org repository, then connect it under **Organization settings → Plugins** (GitHub sync; public repos aren't accepted for org marketplaces).
* **Upload** — download the plugin `.zip` [for your region](#download-and-upload-the-plugin-manually) and upload it under **Organization settings → Plugins**.
Set each plugin's availability (Installed by default / Available for install / Required / Not available).
Then add the Affinda connector under **Organization settings → Connectors** — only Owners / Primary Owners can add custom connectors. Members authenticate individually once it's enabled.
On **Claude Code (CLI)** you can instead allow the public marketplace directly by adding `affinda/skills` to `strictKnownMarketplaces` (or `extraKnownMarketplaces`) in managed settings — no fork required.
On a managed account you generally **can't** add a marketplace or a custom connector yourself. Ask your Claude admin to:
1. Publish the Affinda plugin (**Organization settings → Plugins**), and
2. Enable the Affinda MCP connector (**Organization settings → Connectors**).
Once they have, the plugin appears under **Customize → Browse plugins**, and you authenticate the connector with your own Affinda account.
***
## Common workflows
The following workflows are available as structured guides inside the plugin skill and as MCP prompts on the server (for clients that support prompts). Each can also be triggered by describing what you want to the agent in plain language.
Ask your agent: *"Set up an invoice extractor"* or *"I need to extract invoice data."*
The agent will:
1. Locate your Affinda organisation.
2. Create a workspace with appropriate OCR mode (digital PDFs vs scanned images) and classification settings.
3. Create an Invoice document type and bulk-create the standard field schema (invoice number, dates, vendor, line items, totals, currency).
4. Optionally add validation rules that check totals and line-item sums.
5. Tell you the workspace is ready to receive uploads.
See [Set up an invoice extractor](/integrations/mcp-workflows/setup-invoice-extractor) for the full step-by-step guide.
Ask your agent: *"Set up a resume extractor"* or *"I want to parse CVs."*
The agent calls `create_recruit_workspace`, which provisions a pre-configured "Recruitment" workspace with four document types in a single step: Resume, Job Description, Redacted Resume, and Resume Summary. Classification automatically routes uploads to the right type.
See [Set up a resume extractor](/integrations/mcp-workflows/setup-resume-extractor) for details and custom-schema alternatives.
Ask your agent: *"Why are my extractions wrong?"* or *"Confidence scores are low on field X."*
The agent will:
1. Read the document type configuration and workspace processing settings.
2. Sample recent extractions and identify patterns (one field consistently wrong vs all fields on specific documents).
3. Propose up to three ranked changes — OCR mode first (the most impactful lever), then field-level prompt fixes, then validation rules.
4. Wait for your approval before making any changes.
See [Debug low-confidence results](/integrations/mcp-workflows/debug-low-confidence-results) for the full diagnostic procedure.
Ask your agent: *"Review my documents"* or *"What's in my review queue?"*
The agent lists documents in `review` state, presents field values and confidence scores, and applies your verdict in bulk:
* **Confirm** — marks extractions as validated and feeds them into model memory.
* **Reject** — flags documents as incorrect and signals the model to avoid similar errors.
* **Archive** — removes documents from the active queue without rejection.
* **Reassign** — moves a document to a different document type and triggers a reparse.
See [Human review queue](/integrations/mcp-workflows/human-review-queue) for batching tips and model-memory implications.
***
## Reference
Public clients (Claude Desktop, Claude Code, Cursor, Codex) authenticate via **OAuth 2.1 with Dynamic Client Registration**. You log in with your existing Affinda account credentials; no API keys or JWTs need to be handled manually.
The OAuth flow:
1. Your MCP client sends a dynamic client registration request to the Affinda authorisation server.
2. Affinda redirects you to log in (browser window or embedded prompt, depending on your client).
3. After approval, the client receives an access token scoped to `misc:mcp` and stores it for subsequent requests.
4. All tool calls carry this token as a Bearer header; the MCP server verifies it locally against Affinda's JWKS.
Tokens are managed automatically by your MCP client — there is nothing to rotate or store yourself.
Affinda operates in three isolated regions and your account lives in exactly one. Your MCP endpoint is the **same address you sign in to Affinda from, with `app.` swapped for `mcp.`**:
| Region | You sign in at | MCP endpoint |
| ------------------- | ----------------------------- | --------------------------------- |
| Australia (AP1) | `https://app.affinda.com` | `https://mcp.affinda.com/mcp` |
| United States (US1) | `https://app.us1.affinda.com` | `https://mcp.us1.affinda.com/mcp` |
| Europe (EU1) | `https://app.eu1.affinda.com` | `https://mcp.eu1.affinda.com/mcp` |
If you're unsure which region your account uses, log in to the Affinda app and check the URL in your browser's address bar. Connecting to the wrong region authenticates successfully but returns no workspaces.
The MCP connector works with any document type configured in your Affinda account. Common use cases include:
* **Invoices** — vendor invoices, supplier bills, expense receipts
* **Resumes and CVs** — candidate applications, job descriptions
* **Contracts** — agreements, NDAs, statements of work
* **Identity documents** — passports, driver licences, ID cards
* **Financial documents** — bank statements, payslips, tax forms
* **Custom document types** — any structured or semi-structured document type you define in Affinda
Document formats supported by the underlying platform: PDF, DOC, DOCX, XLSX, ODT, RTF, TXT, HTML, PNG, JPG, TIFF, and JPEG.
The server exposes approximately 75 tools organised by resource domain:
| Domain | Example tools |
| ---------------- | ----------------------------------------------------------------------------------------------------- |
| Organisations | `list_organizations`, `get_organization` |
| Workspaces | `create_workspace`, `update_workspace`, `list_workspaces` |
| Documents | `upload_document`, `get_document`, `get_document_extraction`, `confirm_documents`, `reject_documents` |
| Document types | `create_document_type`, `list_document_types`, `create_recruit_workspace` |
| Fields | `bulk_create_fields`, `create_field`, `update_field`, `delete_field` |
| Validation rules | `create_validation_rule`, `delete_validation_rule` |
| Data sources | `create_data_source`, `add_value_to_data_source`, `bulk_add_values_to_data_source` |
| Integrations | `create_integration`, `update_integration`, `list_integrations` |
| API tokens | `create_api_token`, `list_api_tokens`, `revoke_api_token` |
For the full tool catalog with parameter details, see the [API Reference](/reference/getting-started).
| Symptom | Likely cause | Fix |
| ---------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Authentication prompt does not appear | Client is not requesting OAuth flow | Re-add the connector; ensure your client supports OAuth 2.1 DCR |
| `list_workspaces` returns empty | Authenticated as the wrong account or wrong region endpoint | Sign out, remove the connector, and re-add with the endpoint matching your account's region |
| Tool calls return 401 | Expired or revoked access token | Disconnect and reconnect the integration to trigger a fresh OAuth login |
| `wait_for_document_processing` times out | Document is large or the processing queue is busy | Call `get_document` to poll the status manually; the 300-second cap will have been reached |
| Agent picks the wrong tool | Tool descriptions don't match user intent | File a bug at [github.com/affinda/skills](https://github.com/affinda/skills) |
# Debug low-confidence extraction results with your AI agent
Source: https://docs.affinda.com/integrations/mcp-workflows/debug-low-confidence-results
Diagnose and fix low-confidence Affinda extractions through an MCP-connected AI agent, covering OCR mode, field configuration, and validation rules.
When extraction accuracy is lower than expected, this workflow walks your AI agent through a structured diagnosis — checking the most impactful configuration settings first before suggesting schema changes.
**Trigger phrases that start this workflow:**
* "Why are my extractions wrong?"
* "Confidence scores are low"
* "Field X keeps coming out wrong"
* "Can we improve accuracy?"
Before starting, your AI client must be connected to the Affinda MCP server. See [MCP Connector and Plugin](/integrations/mcp-connector) for setup instructions.
***
## Steps
If you have not named the document type causing the issue, the agent lists your document types and asks you to confirm which one to investigate.
The agent reads the full document type configuration including field list, field types, `transformation_prompt` values, and attached validation rules.
The agent reads the workspace settings. Three settings explain the majority of low-confidence cases:
| Setting | Problem scenario | Fix |
| --------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------- |
| `ocr_mode: skip` | Document is an image or scanned PDF | Change to `always-partial` or `always-full` |
| `ocr_mode: always-partial` | Document is a scanned image, not a digital PDF | Change to `always-full` |
| `enable_document_classification: false` | Multiple document types in one workspace; wrong schema applied to uploads | Enable classification |
| `model_memory_strategy: manual` | No confirmed examples marked | Switch to `auto` |
Setting `ocr_mode` to `skip` on a workspace that receives any scanned or photographed documents will produce empty extractions, not just low-confidence ones. This is the most common cause of complete extraction failure.
The agent pulls 3–5 recent confirmed documents and reads their per-field confidence scores. The pattern tells you where to focus:
| Pattern | Diagnosis |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| One field consistently low across documents | That field's `transformation_prompt` needs refinement, or the field type is wrong (e.g. `text` where `date` is expected) |
| All fields low on specific documents | Those documents likely have an OCR-mode mismatch — check whether they are scans vs digital |
| All fields low across all documents | Upstream issue — check OCR mode first, then classification, then field schema |
The agent calls `list_recent_field_annotations` to see which fields users have been correcting most frequently. Repeated manual corrections on the same field are a strong signal that the field's prompt or type is wrong.
Based on the evidence gathered, the agent presents at most three recommendations in order of expected impact:
1. **OCR mode change** — largest single lever; takes effect on the next upload.
2. **Field-level fix** — refine the `transformation_prompt` on the problematic field, or change its type if the current type is wrong.
3. **Validation rule** — add a rule to flag suspect extractions for human review rather than relying on raw confidence.
The agent shows you the supporting evidence (for example: *"8 of 10 sampled documents had low confidence on `vendorAddress`"*) before proposing changes.
The agent will not apply any changes — `update_workspace`, `update_field`, or `create_validation_rule` — until you explicitly approve each one. Review the recommendations and confirm which you want applied.
***
## What this workflow does not fix
Some documents are legitimately difficult — low-quality scans, handwritten notes, inconsistent layouts. Confidence will be low on these regardless of configuration. The workflow flags this case rather than suggesting spurious fixes.
A brand-new document type with fewer than ten confirmed documents will improve substantially over the next ten confirmations regardless of configuration tuning. If you have only just created the document type, the best action is to confirm a batch of documents and let model memory do its work.
If `always-full` OCR is producing unusable or garbled text, the problem is upstream of the schema. The agent will surface this and suggest contacting [support@affinda.com](mailto:support@affinda.com) rather than continuing to chase field-level fixes.
***
## Related
* [Human review queue](/integrations/mcp-workflows/human-review-queue) — if users are manually correcting many fields, run the review queue workflow to catch patterns early.
* [Configuration guide: Confidence](/configuration/confidence) — how confidence scores are calculated and how to interpret them.
* [Configuration guide: OCR](/configuration/ocr) — OCR mode options explained.
# Manage a human review queue with your AI agent
Source: https://docs.affinda.com/integrations/mcp-workflows/human-review-queue
Use an MCP-connected AI agent to list documents awaiting review, inspect extractions, and bulk-confirm, reject, archive, or reassign queue items in Affinda.
This workflow walks through using an MCP-connected AI agent to manage the document review queue — listing documents waiting for a human decision, inspecting their extracted data, and applying verdicts in bulk.
**Trigger phrases that start this workflow:**
* "Review my documents"
* "What's in my review queue?"
* "Confirm the invoices I just uploaded"
* "I want to validate my extractions"
Before starting, your AI client must be connected to the Affinda MCP server. See [MCP Connector and Plugin](/integrations/mcp-connector) for setup instructions.
***
## Document states
Documents move through the following states:
```
pending → processing → review → validated
```
| State | Meaning |
| ------------------------ | ----------------------------------------------------------------------------------------------- |
| `pending` / `processing` | Document is still being extracted. Nothing to review yet. |
| `review` | Extraction complete; waiting for a human decision. This is the queue this workflow operates on. |
| `validated` | Confirmed by a human or by auto-confirmation rules. |
| `archived` | Removed from the active queue; no longer needs action. |
***
## Steps
The agent calls `list_documents` with `state=review` and returns up to 20 documents waiting for a decision. If the queue is empty, there is nothing to review.
You can narrow the queue by workspace or document type: *"Show me the invoice review queue."*
For any document you want to examine in detail, ask: *"Show me the extraction for document \[ID or name]."*
The agent calls `get_document` (for status and metadata) and `get_document_extraction` (for field values and confidence scores), then surfaces the results with low-confidence fields highlighted so you know where to look first.
Tell the agent your decision in plain language. It will identify the relevant tool and batch the operation:
| What you say | Tool called |
| --------------------------------- | --------------------------------------------------------------- |
| "These look right — confirm them" | `confirm_documents(document_ids=[...])` |
| "These are wrong — reject them" | `reject_documents(document_ids=[...])` |
| "I don't need these any more" | `archive_documents(document_ids=[...])` |
| "This is the wrong document type" | `reassign_document_type(document_id=..., document_type_id=...)` |
You can refer to multiple documents at once: *"Confirm all of these."* The agent batches them into a single call rather than looping per document.
***
## Model memory and confirmation
`confirm_documents` does more than mark a document as validated — it feeds the extraction into the workspace's model memory, directly improving future accuracy. The effect depends on the workspace's `model_memory_strategy`:
| Strategy | Behaviour |
| ---------------- | ------------------------------------------------------------------------------------ |
| `auto` (default) | The system selects which confirmed documents become training examples automatically. |
| `manual` | Only documents you explicitly mark as training examples are used. |
| `always` | Every confirmed document is added as a training example. |
When you confirm a document for the first time, the agent will mention this so you understand that confirmation is not just "approve and forget" — it is also "approve and teach the model".
***
## Rejection vs archiving
These two operations are distinct:
* **Reject** (`reject_documents`) — marks an extraction as incorrect. Rejection participates in model memory: the system learns to avoid repeating the same mistake on similar documents.
* **Archive** (`archive_documents`) — removes a document from the active queue because it is no longer needed. Archiving does not signal to the model that the extraction was wrong.
Use rejection for bad extractions. Use archiving for documents that were processed correctly but are no longer relevant.
***
## Document reassignment
If a document was routed to the wrong document type (for example, a receipt was classified as an invoice), use `reassign_document_type`. The agent will:
1. Verify that the target document type is assigned to the workspace.
2. Call `assign_document_type_to_workspace` first if it is not.
3. Call `reassign_document_type`, which triggers a reparse under the new schema.
The document briefly returns to `processing` state during the reparse. Tell the agent you are expecting this and it will confirm once the new extraction is ready.
***
## Related
* [Debug low-confidence results](/integrations/mcp-workflows/debug-low-confidence-results) — if users are repeatedly correcting the same field, this is the next step.
* [Configuration guide: User Validation](/configuration/user-validation) — details of the Affinda validation interface for human reviewers.
* [Configuration guide: Machine Validation](/configuration/machine-validation) — setting up auto-confirmation rules so clean documents bypass the review queue.
# Set up an invoice extractor with your AI agent
Source: https://docs.affinda.com/integrations/mcp-workflows/setup-invoice-extractor
Step-by-step guide to creating an Affinda workspace and invoice extraction schema through an MCP-connected AI agent, covering OCR mode, fields, and validation.
This workflow walks through everything your AI agent does when you ask it to set up an invoice extractor. You can follow along to understand each step, or simply ask your agent and let it run the sequence for you.
**Trigger phrases that start this workflow:**
* "Set up an invoice extractor"
* "I need to extract invoice data"
* "How do I process invoices in Affinda?"
Before starting, your AI client must be connected to the Affinda MCP server. See [MCP Connector and Plugin](/integrations/mcp-connector) for setup instructions.
***
## Steps
The agent calls `list_organizations` to find your Affinda organisation. If you have more than one, it will ask which one to use. If none are returned, your Affinda account does not yet have an organisation — sign in to the Affinda app to create one first.
The agent creates a workspace named "Invoices" (or a name you specify) with these defaults:
| Setting | Default | When to change |
| -------------------------------- | ---------------- | -------------------------------------------------------------------------------------- |
| `visibility` | `organization` | Change to `private` if only one team should access it |
| `ocr_mode` | `always-partial` | Change to `always-full` if you receive scanned or photographed invoices |
| `enable_document_splitting` | `false` | Enable if you upload batches of invoices as a single file |
| `enable_document_classification` | `true` | Leave enabled to catch mis-uploaded documents |
| `reject_duplicates` | `true` | Leave enabled to avoid processing the same invoice twice |
| `model_memory_strategy` | `auto` | Leave on `auto`; accuracy improves noticeably after the first \~10 confirmed documents |
If you receive scanned invoices, tell your agent explicitly: *"We receive scanned invoices by email."* The agent will set `ocr_mode` to `always-full`, which is the most important single configuration choice for image-based documents.
If you upload batches containing multiple invoices per file, mention this and the agent will enable splitting and select the appropriate document splitter automatically.
The agent creates an "Invoice" document type under your organisation and attaches it to the workspace.
The agent bulk-creates all fields in a single call. The standard invoice schema is:
| Field slug | Label | Type |
| ----------------------- | -------------- | ----- |
| `invoiceNumber` | Invoice Number | text |
| `invoiceDate` | Invoice Date | date |
| `dueDate` | Due Date | date |
| `vendorName` | Vendor Name | text |
| `vendorAddress` | Vendor Address | text |
| `billTo` | Bill To | text |
| `subtotal` | Subtotal | float |
| `taxAmount` | Tax | float |
| `totalAmount` | Total | float |
| `currency` | Currency | text |
| `lineItems` | Line Items | table |
| `lineItems.description` | Description | text |
| `lineItems.quantity` | Quantity | float |
| `lineItems.unitPrice` | Unit Price | float |
| `lineItems.amount` | Amount | float |
You can ask the agent to adjust this schema before or after creation. Adding fields later is fine, though fields added early benefit from model memory on all subsequent documents.
The agent will offer to add two validation rules:
1. **Subtotal + tax = total** — flags documents where the arithmetic doesn't add up.
2. **Line-item sum = subtotal** — flags documents where individual line amounts don't match the subtotal.
These rules send flagged documents to the review queue rather than auto-confirming them. Accept or decline based on your workflow.
Your workspace and document type are configured. You can now:
* Upload invoice files via the Affinda app (drag and drop) or the API.
* Use the agent to upload: *"Upload this invoice: \[URL or file path]."*
* Ask the agent to check the review queue: *"What invoices are waiting for review?"*
***
## Variants
If your invoices do not show a separate subtotal and tax (e.g. all amounts are GST-inclusive), remove `subtotal` and `taxAmount` from the schema and keep only `totalAmount`. Tell the agent: *"Our invoices only show a total amount inclusive of tax."*
For organisations that receive invoices in multiple currencies, connect the `currency` field to a data source of accepted ISO currency codes. Ask the agent: *"Connect the currency field to a list of accepted currencies."* The agent will walk through the `connect-validation-data` workflow.
If you need to match invoices against purchase orders, add a `purchaseOrderNumber` (text) field. Tell the agent: *"Add a purchase order number field."*
Connect the `vendorName` field to a data source of approved vendors so the system flags invoices from unknown suppliers. Ask: *"Validate vendor names against our approved vendor list."*
If your accounting software exports multiple invoices as a single PDF, enable document splitting. Tell the agent: *"We receive batches of invoices as a single file."* The agent will enable splitting and select the General Document Splitter automatically.
***
## What to expect after setup
* The first few uploads will be extracted immediately, but confidence on vendor-specific fields may be moderate until model memory has seen confirmed examples.
* After approximately 10 confirmed documents, extraction accuracy improves noticeably for recurring vendors and layouts.
* If accuracy is still low after sufficient uploads, see [Debug low-confidence results](/integrations/mcp-workflows/debug-low-confidence-results).
# Set up a resume extractor with your AI agent
Source: https://docs.affinda.com/integrations/mcp-workflows/setup-resume-extractor
Use the Affinda MCP connector to create a recruitment workspace with resume parsing, job description extraction, and redaction in a single agent command.
This workflow walks through setting up resume and CV extraction through an MCP-connected AI agent. Affinda provides a purpose-built one-call setup that provisions everything needed for a recruitment pipeline.
**Trigger phrases that start this workflow:**
* "Set up a resume extractor"
* "I want to parse CVs"
* "Build a recruitment workspace"
* "Read job descriptions automatically"
Before starting, your AI client must be connected to the Affinda MCP server. See [MCP Connector and Plugin](/integrations/mcp-connector) for setup instructions.
***
## Steps
The agent calls `list_organizations` to find your Affinda organisation. If you have more than one, it will ask which one to use.
The agent calls `create_recruit_workspace`, which creates a "Recruitment" workspace pre-loaded with four document types in a single step:
| Document type | What it extracts |
| ------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Resume** | Full structured candidate data: work history, education, skills, contact details, languages, certifications |
| **Job Description** | Role title, requirements, location, salary signals, responsibilities |
| **Redacted Resume** | Same fields as Resume with personally identifiable information removed |
| **Resume Summary** | Auto-generated condensed view of the candidate profile |
The workspace is pre-configured with OCR mode, classification, and model memory settings tuned for the recruitment domain. No further configuration is needed for the standard pipeline.
`create_recruit_workspace` is idempotent at the workspace level: calling it again when a "Recruitment" workspace already exists in the organisation updates the existing one rather than creating a duplicate.
Your workspace is immediately ready to receive files. Classification automatically routes uploads to the correct document type — you do not need to specify whether a file is a resume or a job description.
Upload via the Affinda app (drag and drop), the API, or ask the agent: *"Upload this resume: \[URL or file path]."*
***
## Extending after setup
Once the standard workspace is running, common follow-up requests include:
Ask your agent: *"Add a candidate ID field to the Resume document type."*
The agent will create a `candidateId` text field on the Resume document type. You can populate this field via the API when pushing candidates into your ATS.
Connect the "skills" field on the Resume document type to a data source of allowed skill values. This lets the system flag extractions that contain skills outside your taxonomy.
Ask: *"Validate resume skills against our approved skills list."* The agent will walk through the connect-validation-data workflow.
Configure an integration endpoint so confirmed documents automatically push structured data to your ATS or HRIS.
Ask: *"Set up an integration to push confirmed resumes to \[your system]."*
If you need a reduced or domain-specific field set (for example, only candidate name, email, and years of experience for a pre-screening tool), use the custom path instead of `create_recruit_workspace`:
1. Ask the agent to create a workspace with `create_workspace`.
2. Ask it to create a document type with `create_document_type`.
3. Describe the fields you need and it will bulk-create them with `bulk_create_fields`.
This gives you full control over the schema, though you lose the pre-configured OCR and classification settings that `create_recruit_workspace` applies.
***
## What to expect after setup
* Classification routes uploads automatically — no need to specify document type per upload.
* Resume extraction covers a broad structured schema out of the box; no field configuration is required for the standard pipeline.
* Model memory is enabled by default. Confirmed documents improve extraction accuracy over time.
* If you need to search and rank candidates against job descriptions, see [Affinda's Search and Match product](/resumes/search-match).
# API authentication with rotatable keys
Source: https://docs.affinda.com/reference/authentication
Authenticate requests to the Affinda API using rotatable API keys, including how to generate, rotate, and revoke keys for production and test environments.
Affinda's API uses basic authentication with API keys. Each Affinda user will have their own API keys to manage within their [user profile settings](https://app.affinda.com/settings). API keys are not associated with an Organization.
Each API key is only viewable once when created for security purposes. As a result, users should copy their API keys and store them securely in their environment.
API keys can always be re-generated if a user fails to copy their initial key.
## Key rotation
Users can manage API keys effectively via the rotation capabilities offered through the web app.
* **Viewing the key:** Once you create a key, you can only view it once within your user settings page in the application. It is crucial that you copy and store it in a safe location within your environment.
* **Maximum of 3 API keys:** You can generate a maximum of three API keys within the Affinda app.
* **Naming and Expiry:** Each API key can be named and set with an expiry date or to never expire, based on your requirements.
# Official client libraries for the Affinda API
Source: https://docs.affinda.com/reference/client-libraries
Use Affinda's open-source client libraries to integrate the API quickly from Python, JavaScript, TypeScript, .NET, and Java applications.
Affinda maintains several open-source client libraries that we recommend customers use. These libraries make it easy to use the API from C#/.NET, Java, Python, and Node.js. Each library is a thin wrapper around the API that handles requests, authentication, and signing. The libraries' READMEs on GitHub fully document them.
Client libraries are available for the following languages:
* [Python](https://github.com/affinda/affinda-python)
* [Javascript](https://github.com/affinda/affinda-typescript)
* [.NET](https://github.com/affinda/affinda-dotnet)
* [Java](https://github.com/affinda/affinda-java)
# Embed the Affinda validation interface
Source: https://docs.affinda.com/reference/embedded
Embed the Affinda document validation interface inside your own application using iframes or SSO, including configuration options and authentication tokens.
Using Affinda in 'Embedded Mode' enables users to integrate Affinda’s document validation UI directly into their own applications, creating a seamless experience for end-users. This method is designed to keep users within your application ecosystem while leveraging Affinda’s powerful extraction and processing capabilities.
Processed documents and extracted data are rendered directly within your application, removing the need for users to log in to multiple platforms.
Delivers the benefits of a 'human in the loop' solution to ensure the data extracted is 100% accurate.
When using the validation UI, the data from these user corrections creates a feedback loop that improves model performance over time.
Data is processed and made available instantly for users.
Adjust the interface to align with your branding and user experience requirements.
## How it works
1. Within the API or webhook response from any documents sent to Affinda, we return a value called `meta.reviewUrl`
2. This signed and authenticated URL can be embedded as an iFrame within your platform (or open as a new tab in the browser), and allow members of your team to validate the predicted data and add any additional data points
3. Once a document is 'Confirmed', the validated data can be requested or, more commonly, sent via a [webhook](https://docs.affinda.com/docs/webhooks)
4. This data is ingested into your platform for downstream processing with full confidence in the accuracy
## Implementation
For security reasons, each signed URL is valid for 60 minutes.
The review link you receive contains an embedded access token. Because it’s part of the URL, it can easily show up in places you don’t control — like server logs, browser history, referrer headers, email threads, support tickets, or even old backups. If someone gets hold of that URL, they can use it to access the content without logging in. By making these links expire quickly, we reduce the potential impact if one leaks. Even if a database backup or log file were exposed later, any captured links would no longer work.
We recommend that users treat the URL as ephemeral and fetch it on demand:
1. **Store only the Affinda document ID** in your system, not the review URL.
2. **When a user needs to view a document**, your backend requests a fresh review URL from Affinda (using `GET / document`) and returns it to the client.
3. **Embed that URL in an iframe** in your application (or open it directly if preferred).
4. **Do not persist the URL** anywhere durable; consider it single-use/short-lived.
**Hygiene:** avoid putting the URL in emails, analytics, or logs; pass it directly from your backend
## Configuration Options
To customize the theme in embedded mode, get in [contact with the Affinda team. ](https://www.affinda.com/contact)
* Light or dark mode
* Background colour
* Text colour
* Primary colour (pink by default)
* Error colour (red)
* Warning colour (orange)
* Info colour (blue)
* Success colour (green)
* Annotation colour (yellow)
* Used for anything with rounded corners, eg., buttons, annotations, popovers
* Font family (system font by default; can use any system font, Adobe Fonts, Google Fonts)
* Base font size
* Font weights (regular, medium, bold)
The following actions / capabilities can be enabled or disabled:
* Confirm document
* Collection selector
* Export data
* Filename
* Tags
* Warnings
Theming customisations are only available in Embedded Mode, not when using the main Affinda application.
# API quick start guide
Source: https://docs.affinda.com/reference/getting-started
Quick start for the Affinda API: create an API key, upload your first document, retrieve extracted data, and integrate the response into your application.
The Affinda Agent helps teams quickly integrate with 1,000s of systems. See our [Tutorial: Creating your integration with the Affinda Agent](/handbook/agent-integrations) for a comprehensive step-by-step guide.
Affinda's Document AI API turns any incoming document — from invoices and résumés to passports and bills of lading — into clean, structured JSON you can drop straight into your workflow. Behind the scenes our models have already processed more than **250 million documents for 500 + organisations in 40 countries**; the API is the thin, dependable interface that lets your own code tap that capability.
## Relevant tutorials
Click here to learn about common integration workflows for different use cases and requirements.
Click here to learn about connecting Affinda to your system with our no-code integrations built using the Affinda Agent.
## AI Agent Integration Resource
To assist with creating integrations to the Affinda Platform, we've published a comprehensive integration resource designed specifically for AI coding agents (Cursor, Claude, Copilot, etc.)
This single markdown file contains everything an agent needs to build an Affinda integration end-to-end: API basics, authentication, Python & TypeScript clients, structured outputs, webhooks, upload patterns, common errors, and a full map of our documentation
**Two ways to use it:**
* **Direct link:** Ask your agent to read [https://docs.affinda.com/skill.md](https://docs.affinda.com/skill.md) before starting your integration
* **Persistent skill:** Install with `npx skills add affinda/skills` so your agent always has access
This resource enables you to build a working integration without jumping across multiple documentation pages
## Design principles
* **Few moving parts**: A small set of REST resources (`/documents`, `/document_types`, `/workspaces`) covers the vast majority of use-cases.
* **Works straight away, yet customisable**: Upload a PDF and retrieve JSON in a single call, or fine-tune behaviour with model versions, human-in-the-loop validation and post-processing rules.
* **Document-agnostic by design**: The same endpoint handles an invoice today and a payslip tomorrow; just swap the **document type ID**, not your integration.
* **Observability built-in**: Every response carries processing timestamps and confidence scores; webhook signatures let you verify payloads.
* **Secure at scale**: ISO 27001 certified, SOC 2 compliant, API keys scoped per user, with regional endpoints to keep data where you need it.
See our [Tutorial: Solution Design ](/academy/solution-design)to learn more about common integration workflows for different use cases and requirements.
## Core primitives
| Primitive | Purpose |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Document** | The file you upload (PDF, image, DOCX, etc.) plus its extracted data and metadata. |
| **Document Type** | A model configuration that defines how a specific kind of document (invoice, résumé, passport, custom layout, …) is parsed. |
| **Workspace** | Logical container that groups documents, permissions and webhook settings. |
With just these three concepts, you can automate the extraction of structured data from any document type.
## Prerequisites
Before you make your first API call, you'll need to:
1. **Create an Affinda account** and log in to the dashboard.
2. **Generate an API key** (*Settings* → *API Keys*).
3. **Configure a document type** (See our step-by-step tutorial on [Creating a New Model](/academy/model-creation)).
4. **Retrieve the workspace identifier** (*Workspace* → *Workflow* → *Integrations*).
API base URL
Use the base URL for the region where you created your account:
* **AU (Global):** `https://api.affinda.com`
* **US:** `https://api.us1.affinda.com`
* **EU:** `https://api.eu1.affinda.com`
Your API key only works against the instance where it was generated. If you're unsure, check the URL of the app you signed into.
For volume limits and plan tiers, see [Affinda's pricing plans](https://www.affinda.com/pricing-plans).
## Parse your first document
```bash cURL theme={null}
# 1. Set your API key (found in the Affinda dashboard)
export AFFINDA_API_KEY="aff_562..."
export AFFINDA_API_BASE="https://api.affinda.com" # AU (Global). Use https://api.us1.affinda.com for US or https://api.eu1.affinda.com for EU.
# 2. Upload a document and wait for processing to finish
curl -X POST $AFFINDA_API_BASE/v3/documents \
-H "Authorization: Bearer $AFFINDA_API_KEY" \
-F "file=@sample_invoice.pdf" \
-F "workspace=YOUR_WORKSPACE_IDENTIFIER"
```
```python Python theme={null}
# !pip install affinda
from pathlib import Path
from affinda import AffindaAPI, TokenCredential
API_KEY = "YOUR_API_KEY" # replace with your actual key
WORKSPACE_ID = "YOUR_WORKSPACE_IDENTIFIER" # e.g. "vBAdDBer"
FILE_PATH = Path("resume.pdf") # path to the file you want to parse
# Use the base URL for your region:
# AU (Global): https://api.affinda.com
# US: https://api.us1.affinda.com
# EU: https://api.eu1.affinda.com
API_BASE = "https://api.affinda.com"
# Set up the client
credential = TokenCredential(token=API_KEY)
client = AffindaAPI(credential=credential, endpoint=API_BASE)
# Upload the document and wait until processing finishes
with FILE_PATH.open("rb") as f:
doc = client.create_document(
file=f,
workspace=WORKSPACE_ID,
)
# Access parsed data
print(doc.data)
```
```javascript Node.js theme={null}
import { AffindaAPI, AffindaCredential } from "@affinda/affinda";
import * as fs from "fs";
// Use the base URL for your region:
// AU (Global): https://api.affinda.com
// US: https://api.us1.affinda.com
// EU: https://api.eu1.affinda.com
const API_BASE = "https://api.affinda.com";
const credential = new AffindaCredential("YOUR_API_KEY");
const client = new AffindaAPI(credential, API_BASE);
const file = fs.createReadStream("resume.pdf");
client
.createDocument({
file,
workspace: "YOUR_WORKSPACE_IDENTIFIER",
})
.then(doc => {
console.log("Parsed data:", doc.data);
})
.catch(err => console.error("Error:", err));
```
# API volume, file size, and rate limits
Source: https://docs.affinda.com/reference/limits
Reference for Affinda's API rate limits, file size and page limits, supported file types, and concurrent upload thresholds for parsing and extraction.
In order to maintain a stable and cost-efficient platform, Affinda enforces certain volume limits (rate limits) and file limits for customers.
## Volume Limits
There is no limit to the number of documents you can submit to the Affinda API. However, you will be limited to **20 documents per minute** that will be processed by our high priority queue. If you would like to specify which queue to use, you can set the `lowPriority` parameter during document submission. Note that if you explicitly set `lowPriority` to `false`, and if you have exceeded the high priority queue rate limit, you will receive a 429 (Too Many Requests) response.
### Scenario 1
You use Affinda to prepopulate a web form based on a document uploaded by a user. During peak periods you need to parse as many as 15 documents per minute.
You should send documents to Affinda without specifying `lowPriority`. By default, almost all of your documents will be processed in our high-priority queue. If some occasional documents fall into our low-priority queue, they will still likely be parsed in a timely manner.
### Scenario 2
You would like to parse 100,000 documents as quickly as possible.
You should send all of the documents to Affinda without specifying `lowPriority`. You probably want to set the `wait` parameter in the request to `false`, meaning that the request will return immediately without waiting for the document to parse. The results can be retrieved on completion using [webhooks](https://docs.affinda.com/docs/webhooks) or by retrieving the result with a GET request.
### Scenario 3
You have the requirements of both scenarios 1 and 2. i.e., you have ongoing requests by users that should be returned immediately and occasional bulk uploads that can be processed asynchronously.
You simply need to ensure that all of your bulk uploads are submitted with `lowpriority` equal to `true`. This way, your high-priority rate limit will be reserved for requests made by users on your app.
## File Limits
### File Size
The maximum file size that can be uploaded to Affinda is **20MB**. This is intended to be in line with popular email providers.\
Note: Resume upload file size is limited to 5MB.
### Page Limit
The default page limit for all customers is **20 pages**. This limit may be increased on a case-by-case basis by request. Please get in contact with your Affinda account manager for details.
# Field and document metadata in API responses
Source: https://docs.affinda.com/reference/metadata
Reference for field and document metadata returned in the Affinda API response, including bounding boxes, page numbers, parsed values, and confidence scores.
In addition to the specific data extracted from the documents, the API response includes field- and document-level metadata to assist with document processing.
## Field-level metadata
Identifier associated with the specific data point
x/y coordinates for the rectangular bounding box containing the data
The page that the data is found on
Raw data extracted before any processing and formatting
Overall confidence that the extracted data is correct
Confidence that the model classified the data correctly
Confidence that text was correctly extracted from the document
Indicates whether the data has been validated by any means
Indicates whether the data has been validated by a human
Indicates whether the data was auto-validated
Unique identifier associated with this data field
Type of data (text, date, date-time, enum, location, float or decimal)
Parsed data after post-processing and mapping
## Document-level metadata
Unique identifier for the document (can be supplied on upload)
Optional file name of the document
True when the document has finished processing
Date-time when the document became ready
True if an exception occurred during processing
ISO-8601 date-time when the document will be auto-deleted
The document’s language
URL to the PDF version of the document
Identifier of the original document if this one was split
Identifiers of child documents if this one was split further
Total number of pages
Whether OCR was applied to extract text
Overall confidence in OCR text extraction
Signed URL (60 min) for human review
Extractor (AI model) associated with the collection
Collection that the document belongs to
Workspace containing the collection and document
When the document was archived
Whether the document is archived
When the document was confirmed
Whether the document is confirmed
When the document was rejected
Whether the document is rejected
When the document was created in Affinda
Error code if processing fails.
Error detail if processing fails.
URL to view the original file
Tags applied to the document
User who last confirmed the document
User who last archived the document
Email file URL if the document was created via email ingestion
# Structured outputs with Pydantic models
Source: https://docs.affinda.com/reference/pydantic-models
Generate structured outputs using Pydantic models from your document types and ensure type-safe validation of Affinda API responses.
Users of our [Python client library](https://pypi.org/project/affinda/) can generate pydantic models to help with validating and consuming the API response in a type-safe way.
Use the `generate_models` command to auto-generate pydantic models from your document type configuration.
## Pydantic models
For example, this will generate pydantic models for your workspace:
```shell theme={null}
# Assuming your workspace ID is rLERIsHk
python -m affinda generate_models --workspace-id=rLERIsHk
```
You will be prompted for your API key, unless you already have the `AFFINDA_API_KEY` environment variable set.
The generated pydantic model(s) will be in `./affinda_models` by default.
For the list of options available, run:
```shell theme={null}
python -m affinda generate_models --help
```
### Example of using the generated pydantic models
```python theme={null}
from pathlib import Path
from affinda import AffindaAPI, TokenCredential
from affinda_models.resume_parser import ResumeParser
API_KEY = "YOUR_API_KEY" # replace with your actual key
WORKSPACE_ID = "YOUR_WORKSPACE_IDENTIFIER" # e.g. "vBAdDBer"
FILE_PATH = Path("resume.pdf") # path to the résumé you want to parse
# Set up the client
credential = TokenCredential(token=API_KEY)
client = AffindaAPI(credential=credential)
# This will raise `pydantic_core.ValidationError` if the API response
# does not validate against ResumeParser
with FILE_PATH.open("rb") as f:
doc = client.create_document(
file=f,
workspace=WORKSPACE_ID,
data_model=ResumeParser,
)
# Access parsed data
print(doc.parsed) # This is a ResumeParser instance
print(doc.data) # This is the raw JSON response
# This will NOT raise `pydantic_core.ValidationError` if the API response
# does not validate against ResumeParser.
# Instead `parsed` will be None if the API response is not compatible.
with FILE_PATH.open("rb") as f:
doc = client.create_document(
file=f,
workspace=WORKSPACE_ID,
data_model=ResumeParser,
ignore_validation_errors=True,
)
if doc.parsed:
print("API response is valid.")
print(doc.parsed)
else:
print("API response is invalid.")
print(doc.data) # The raw JSON response is still available
```
# Generate TypeScript interfaces
Source: https://docs.affinda.com/reference/typescript-interfaces
Auto-generate TypeScript interfaces from your Affinda document types for type-safe consumption of API responses in JavaScript and TypeScript projects.
Users of our [Typescript client library](https://www.npmjs.com/package/@affinda/affinda) can generate typescript interfaces to help with consuming the API response in a type-safe way.
Use the `affinda-generate-interfaces` command to auto-generate typescript interfaces from your document type configuration.
For example, this will generate typescript interfaces for your Recruitment workspace:
```shell theme={null}
# Assuming your Recruitment workspace ID is "rLERIsHk"
npm exec affinda-generate-interfaces -- --workspace-id=rLERIsHk
```
You will be prompted for your API key, unless you already have the `AFFINDA_API_KEY` environment variable set.
The generated typescript interfaces will be in `./affinda-interfaces` by default.
For the list of options available, run:
```shell theme={null}
npm exec affinda-generate-interfaces -- --help
```
# Document upload options for the API
Source: https://docs.affinda.com/reference/upload-options
Compare options for uploading documents to the Affinda API, including multipart file uploads, URL-based ingestion, base64 payloads, and async processing.
While a range of API endpoints drive the Affinda solution, uploading documents for processing (and receiving the response) is fundamental to the platform.
## Submission and Retrieval Options
When integrating document data extraction (parsing), there are three primary ways to submit documents and retrieve the parsed data:
**Explanation:**
* Users submit a document, and the API processes it immediately
* User application waits and the request stays open (`wait = true` ) until parsing is complete
* When finished, the API directly returns the parsed document data
**Pros:**
* Simplest integration
* Immediate retrieval of results after completion
* Suitable for documents that need to be processed quickly
**Cons:**
* Not suitable for large documents or high-volume scenarios
* Can lead to timeouts for documents requiring lengthy processing
**Ideal Use Case:**
* Interactive apps where quick, synchronous response times are critical
**Explanation:**
* Users submit a document and receive an immediate acknowledgment (document ID)
* User application periodically checks (polls) the API endpoint using repeated GET requests to determine when parsing is complete
* Once processing finishes, user retrieves the parsed data.
**Pros:**
* Avoids connection timeouts; ideal for longer or variable processing times
* Better suited for handling multiple simultaneous document submissions
**Cons:**
* Additional complexity with polling logic
* Generates higher API call volume (frequent polling checks)
* Slight delay between actual completion and data retrieval, depending on polling interval
**Ideal Use Case:**
* High-volume scenarios, large documents, or batch processing jobs where exact completion timing isn't critical.
**Explanation:**
* Users submit a document, receiving an immediate acknowledgment
* Rather than polling, your application receives a webhook (callback notification) directly when the document is ready for export
* In some cases this will be when the document is finished parsing, but in other use cases this may be when the document has been validated
* After receiving the webhook, your application retrieves the parsed data with a GET request.
**Pros:**
* Most efficient asynchronous method—reduces unnecessary polling.
* Lower overall API usage
* Provides real-time notifications upon completion
**Cons:**
* Slightly higher setup complexity (webhook listener infrastructure required)
**Ideal Use Case:**
* Real-time workflows or event-driven architectures where timely data retrieval is essential, or API usage optimization is needed
* Scenarios where the application must wait until the document has been fully validated before receiving results
See [Webhooks](https://docs.affinda.com/docs/webhooks) for more information.
## Request Body
The following parameters may be included in the API POST request to Affinda using the [Upload a document for parsing](https://docs.affinda.com/reference/createdocument) endpoint.
Note, all individual parameters are optional, however, one of the following must be specified:
* File
* URL
Documents should be uploaded to the relevant `Workspace` (and optionally `documentType` specified if the document type is known at upload).
File as binary data blob. Supported formats: PDF, DOC, DOCX, XLSX, ODT, RTF, TXT, HTML, PNG, JPG, TIFF, JPEG.
URL to a document to download and process
Unique identifier for the Workspace to upload the document to. The identifier can be found by either using the Get list of all workspaces endpoint or through the app
Unique identifier for the Document Type to upload the document to. If specified, Workspace must also be specified. Used when the document type is known.
If "true" (default), will return a response only after processing has been completed. If "false", will return an empty data object which can be polled at the GET endpoint until processing is complete
Specify a custom identifier for the document. This may be your internal identifier. Does not need to be unique.
The optional filename of the file. If not specified, uses existing filename.
The date/time in ISO-8601 format when the document will be automatically deleted. Defaults to no expiry. See [Data Retention](/data-retention) for more information.
If "true", parsing will fail when the uploaded document is a duplicate of an existing document; no credits will be consumed. If "false", will parse the document normally, whether it is a duplicate or not. If not provided, will fallback to the workspace settings.
Explicitly mark this document as low priority.
If true, the returned parse result (assuming wait is also true) will be a compact version of the full result.
If true, no data will be stored after parsing. Only compatible with requests where wait: True.
If true, the document will be viewable in the Affinda Validation Tool. Set to False to optimize parsing speed
# Webhooks for document and parsing events
Source: https://docs.affinda.com/reference/webhooks
Configure webhooks to receive event notifications from Affinda when documents are uploaded, parsed, validated, or rejected, including signature verification.
Affinda has implemented webhooks to allow the data extracted by Affinda to be 'pushed' to you when an event occurs (e.g. document parsed or document validated), instead of you having to constantly poll our API to 'pull' the data to your system.
**Webhooks can be created at an Organization or Workspace level**
## RESThooks
We have implemented a slightly extended version of webhook called “RESTful webhook”, or “resthook”. It allows you to programmatically manage webhook subscriptions like you would with any RESTful resources.
For end-users, it means setting up a webhook subscription is a matter of clicking buttons, and no copy-pasting of URLs and cryptic tokens.
## Create a webhook subscription
There are 2 steps to creating a webhook:
1. Subscribe to an event
2. The receiver confirms its intention to subscribe
## Subscribe to an event
### Request
**URL:** [https://api.affinda.com/v3/resthook\_subscriptions](https://api.affinda.com/v3/resthook_subscriptions)\
[(endpoint details here) ](https://docs.affinda.com/api-reference/webhooks/create-a-resthook-subscription)
**Method:** POST
**Body:**
```json theme={null}
{
"targetUrl": "https://your-receiver-domain.com/receive/",
"event": "document.parse.completed",
"organization": "{{organization_identifier}}"
}
```
**Available events:**
| **Event Name** | **Description** |
| :-------------------------- | :---------------------------------------------------------------------------------- |
| document.parse.completed | Document has completed parsing, the parsing may have succeeded or failed |
| document.parse.succeeded | Document parsing has succeeded |
| document.parse.failed | Document parsing has failed |
| document.validate.completed | Document has been validated |
| document.classify.completed | Document has completed classifying, the classification may have succeeded or failed |
| document.classify.succeeded | Document classification has succeeded |
| document.classify.failed | Document classification has failed |
| document.rejected | Document has been rejected (automatically or by a user) |
The following events are deprecated in API V3 and should be used only by customers using API V2. API v3 customers should use the 'document' events above.
| **Event Name** | **Description** |
| :---------------------- | :---------------------------------------------------------------------- |
| resume.parse.completed | Resume has completed parsing, the parsing may have succeeded or failed |
| resume.parse.succeeded | Resume parsing has succeeded |
| resume.parse.failed | Resume parsing has failed |
| invoice.parse.completed | Invoice has completed parsing, the parsing may have succeeded or failed |
### Response
**Status code:** 201
**Body:**
```json theme={null}
{
"id": 1,
"event": "document.parse.completed",
"targetUrl": "https://your-receiver-domain.com/receive/",
"organization": {
"identifier": "{{organization_identifier}}",
"name": "{{organization_name}}",
"userRole": "admin",
"avatar": null,
"resthookSignatureKey": "{{resthook_signature_key}}",
"isTrial": false
},
"active": false,
"version": "v3",
"autoDeactivated": false,
"autoDeactivateReason": ""
}
```
## Receiver confirms intention to subscribe
After the last step, we’ll POST to the receiver at [https://your-receiver-domain.com/receive/](https://your-receiver-domain.com/receive/) with a `X-Hook-Secret` header. The receiver should respond to this request with a 200 status code, and then activate the subscription using the `X-Hook-Secret` as below
#### **Request**
**URL:** /v3/resthook\_subscriptions/activate
**Method:** POST
**Headers:**
```text theme={null}
X-Hook-Secret:
```
**Response**
```json theme={null}
{
"id": 1,
"event": "document.parse.completed",
"targetUrl": "https://your-receiver-domain.com/receive/",
"organization": {
"identifier": "{{organization_identifier}}",
"name": "{{organization_name}}",
"userRole": "admin",
"avatar": null,
"resthookSignatureKey": "{{resthook_signature_key}}",
"isTrial": false
},
"active": true,
"version": "v3",
"autoDeactivated": false,
"autoDeactivateReason": ""
}
```
**Example code**
```python theme={null}
import requests
from some_framework import make_response
def receiver(request):
if "X-Hook-Secret" in request.headers:
# Confirm subscibe intention (you can confirm now or save the "X-Hook-Secret" and confirm later)
requests.post(
'https://api.affinda.com/v3/resthook_subscriptions/activate',
headers={
'Authorization': 'Bearer ',
'X-Hook-Secret': request.headers['X-Hook-Secret'],
}
)
return make_response(status_code=200)
else:
# Handle webhook notification
...
```
You have confirmed your intention to subscribe and are now ready to start receiving webhook notifications!
## Receive a webhook notification
### IP whitelisting
If your system requires IP whitelisting for incoming webhook notifications, use the following IP addresses based on your region:
**Australia:**
* 13.55.216.150
* 54.206.255.84
**Europe:**
* 3.75.80.175
* 18.156.30.58
**United States:**
* 34.208.181.154
* 54.245.207.8
### Verify webhook payload integrity
#### Enable webhook payload signing
**Enable webhook payload signing**
It’s highly recommended to enable webhook payload signing, so that you can verify that the payload indeed comes from Affinda and has not been tampered with.
To enable webhook payload signing, set up a resthook signature key for your account
* Go to [Affinda](https://app.affinda.com/)
* Click on the “Settings” tab of your Organization page
* In the section “Webhook Signature Key”, copy the generated key (or click “Regenerate” to get a new key)
#### **Verify the webhook payload when you receive it**
In the webhook notification that Affinda sends, there’s a header called `X-Hook-Signature` of the following format: `.`.
To verify the webhook payload, sign the request body with the Signature Key you set up in the previous step using SHA256, then compare the resulting signature with the signature found in the X-Hook-Signature header. Only process the data if the signatures match!
Confirm payload timestamp is within a short range of current time to prevent replay attacks.
**Example code**
```python theme={null}
import hashlib
import hmac
import json
import time
from some_framework import make_response
def receiver(request):
if "X-Hook-Secret" in request.headers:
# Confirm subscribe intention
...
else:
# Handle webhook notification
sig_header = request.headers['X-Hook-Signature']
timestamp, sig_received = sig_header.split('.')
sig_key = b'your-signature-key'
sig_calculated = hmac.new(sig_key, msg=request.body, digestmod=hashlib.sha256).hexdigest()
# Verify signature
sig_verified = hmac.compare_digest(sig_received, sig_calculated)
# Verify timestamp to prevent replay attack
body = json.loads(request.body)
now = time.time()
max_timestamp_diff = 10 * 60 # 10 minutes
timestamp_verified = (
body["timestamp"] == int(timestamp) and
now - body["timestamp"] < max_timestamp_diff
)
if sig_verified and timestamp_verified:
print('Data is safe to process')
process_data(body)
else:
print("Spies detected! Don't process the data")
return make_response(status_code=200)
```
### Respond to the webhook notification
If we receive status code 200, the webhook notification is considered successfully received.
If we receive status code 410, the receiver is considered “gone” and we'll automatically delete your webhook subscription.
If we receive any other 4xx, 5xx status code, we’ll retry sending the webhook notification in increasingly wider intervals (exponential backoff retry strategy), and eventually stop retrying after about 1 day.
### Webhook payload reference
The webhook payload is the metadata of the document. You can use it to retrieve the full parsed data if you need to.
```json theme={null}
{
"id": "e3bd1942-635b-4971-b8f1-59543b0b2f1f",
"event": "document.parse.completed",
"timestamp": 1665637107,
"payload": {
"identifier": "abcdXYZ",
"ready": true,
"failed": false,
"readyDt": "2023-02-10T08:05:30.775110Z",
"fileName": "resume.pdf",
"expiryTime": null,
"language": "en",
"pdf": "{{url_to_pdf}}",
"parentDocument": null,
"childDocuments": [],
"pages": [
{
"id": 123,
"pageIndex": 0,
"image": null,
"height": 841.0,
"width": 595.0,
"rotation": 0
}
],
"ocrConfidence": null,
"reviewUrl": null,
"createdDt": "2023-02-10T08:05:28.871650Z",
"errorDetail": null,
"file": "{{url_to_file}}",
"collection": {
"identifier": "abcdXYZ",
"name": "Resume Parses",
"extractor": {
"id": 6,
"identifier": "resume",
"name": "Resume Parse",
"baseExtractor": null,
"validatable": false
}
},
"workspace": {
"identifier": "abcdXYZ",
"name": "Recruitment"
},
"tags": [],
"isOcrd": false,
"isConfirmed": true,
"confirmedDt": "2023-02-10T08:05:30.775110Z",
"isRejected": false,
"rejectedDt": null,
"isArchived": false,
"archivedDt": null,
"errorCode": null
}
}
```
## Update webhook subscription
#### Request
**URL:** [Update a resthook subscription](https://docs.affinda.com/reference/updateresthooksubscription)
**Method:** PATCH
**Body:**
```json theme={null}
{
"event": "document.parse.failed"
}
```
#### **Response**
**Status code:** 200
**Body:**
```json theme={null}
{
"id": 1,
"event": "document.parse.failed",
"targetUrl": "https://your-receiver-domain.com/receive/",
"organization": {
"identifier": "abcdXYZ",
"name": "Affinda",
"userRole": "admin",
"avatar": null,
"resthookSignatureKey": "KEY",
"isTrial": false
},
"active": true,
"version": "v3",
"autoDeactivated": false,
"autoDeactivateReason": ""
}
```
## Delete webhook subscription
#### Request
**URL:** [Delete a resthook subscription](https://docs.affinda.com/reference/deleteresthooksubscription)
**Method:** DELETE
#### Response
**Status code:** 204
## List webhook subscriptions
#### **Request**
**URL:** [Get list of all resthook subscriptions](https://docs.affinda.com/reference/getallresthooksubscriptions)
**Method:** GET
#### **Response**
**Status code:** 200
**Body:**
```json theme={null}
{
"count": 1,
"next": null,
"previous": null,
"results": [
{
"id": 1,
"event": "document.parse.completed",
"targetUrl": "https://your-receiver-domain.com",
"organization": {
"identifier": "abcdXYZ",
"name": "Affinda",
"userRole": "admin",
"avatar": null,
"resthookSignatureKey": "KEY",
"isTrial": false
},
"active": true,
"version": "v3",
"autoDeactivated": false,
"autoDeactivateReason": ""
},
]
}
```
## Retrieve webhook subscription
#### **Request**
**URL:** [Get specific resthook subscription](https://docs.affinda.com/reference/getresthooksubscription)
**Method:** GET
#### **Response**
**Status code:** 200
**Body:**
```json theme={null}
{
"id": 1,
"event": "document.parse.completed",
"targetUrl": "https://your-receiver-domain.com/receive/",
"organization": {
"identifier": "abcdXYZ",
"name": "Affinda",
"userRole": "admin",
"avatar": null,
"resthookSignatureKey": "KEY",
"isTrial": false
},
"active": true,
"version": "v3",
"autoDeactivated": false,
"autoDeactivateReason": ""
}
```
# Additional Affinda resources and links
Source: https://docs.affinda.com/resources
Find additional resources for the Affinda platform, including product updates, the trust center, status page, billing information, and the error glossary.
Stay on top of the latest features, improvements, and release notes.
Check real-time service availability and system performance metrics.
Manage invoices, payment methods, and subscription details.
Understand why you might be hitting errors in Affinda.
Find quick answers to the most common questions.
Get help from the Affinda Agent or lodge a support ticket.
Review our security, compliance, and privacy commitments.
Compare on-premise, private cloud, and SaaS deployment models.
Understand how long we store your data and how to customize retention policies.
# Search and Match scoring algorithm
Source: https://docs.affinda.com/resumes/algorithm
How Affinda's Search & Match algorithm scores candidates against jobs, including the weighting of skills, experience, education, and location signals.
Within the Search & Match solution, Affinda has designed an advanced algorithm that will return the most relevant results based on the search criteria provided, but that also provides flexibility and transparency to users.
Each category is given a score based on the match, and these scores are then combined with user-set category weights to give an overall indication of the match that is used to rank candidates or job suitability.
## Scoring
Our search algorithm outputs raw scores for each field in a non-normalised way, and they can be arbitrarily large depending on the type of the field. In order to make these scores usable, we need to normalize these scores to give a percentage score that is easily understood and comparable.
To do so, we calculate the maximum possible score for each category by taking the sum of each field's highest score and using that as the reference when calculating the % overall score for each resume.
**Search parameters:** Job title and years of experience are specified
* **Candidate #1:**
* Job title score = 0.8
* Years experience = 1
* Overall score = 1.8
* **Candidate #2:**
* Job title score = 1.6
* Years experience = 0
* Overall score = 1.6
* **Maximum score:**
* Highest job title score = 1.6
* Highest years of experience score = 1
* Overall maximum score = 2.6
* **Candidate #1** = 1.8/2.6 = 69%
* **Candidate #2** = 1.6/2.6 = 62%
Category weights are applied to category scores to influence the overall percentage score.
## Inverse Document Frequency
To determine the match for each category, Affinda’s search algorithm considers the relative frequency that a search term appears within resumes or job descriptions. This means that the category scores will consider how rare a match for this criterion is across the wider pool of candidates and, as such, associate higher relevance or importance to this particular criterion.
The result of this is that very common and often generic skills or other criteria (such as management, leadership, and communication) will have a much lower impact on the overall category score compared to more specialised things very relevant to the job or industry. See below for some worked examples in action.
### Worked examples
**Example 1:**
* **Search terms** - ’python’, ‘communication’
* **Candidate A** - matches on python but not communication
* **Candidate B**- matches on communication but not python
**Result** - Candidate A scores higher than Candidate B. The frequency of the term ‘python’ is lower than that of ‘communication’ across the entire pool of candidates searched.
**Example 2:**
* **Search term** - job title: ‘reinsurance analyst’
* **Candidate A** – job title is ‘reinsurance associate’
* **Candidate B** – job title is ‘’financial analyst’
**Result** - Candidate A scores higher than Candidate B. While both candidates match one of the terms in the search, the frequency of ‘reinsurance’ is far lower than ‘analyst’ in the candidate pool, so Candidate A scores higher.
# Resume parsing credits and pricing
Source: https://docs.affinda.com/resumes/credits
How resume parsing credits work in Affinda, including how credits are consumed per document, how to purchase top-ups, and how to monitor credit usage.
## Credit Usage
While the standard pricing unit for other document types is per page, Affinda's products aimed at the Recruitment Technology industry are credited on a per-document basis. This reflects the specialized AI models and processing methods used within these use cases.
### Search & Match usage
When using Candidate Search & Match, a credit is consumed every time a document is added to an index for searching. There is no usage or limits associated with the number of searches made.
## Credit Packages
Pricing packages for the Resume Parser and other similar products are also available at different rates from our standard per-page pricing model. These pre-paid packages provide a pre-determined number of credits over the course of 12 months.
Information on these packages is available here: [https://www.affinda.com/recruitment-ai-pricing](https://www.affinda.com/recruitment-ai-pricing)
## Online payment
For customers who want to commit to a small number of credits to continue their testing, Affinda offers easy self-serve payment from the Billing page within the web application.
1. Select the number of credits you’d like to purchase.
2. Complete your payment securely through Stripe Checkout.
These self-serve purchases are charged at US\$0.20 per credit.
If you would like to purchase one of the packages noted above through the same online payment mechanism, please reach out to the Affinda to enable this option.
# Resume Parser data fields reference
Source: https://docs.affinda.com/resumes/data-extracted
Comprehensive reference for fields extracted by Affinda's Resume Parser, including personal details, work history, education, skills, certifications, and more.
* Candidate Name (Title, First, Middle and Last)
* Date of Birth
* Birthplace
* Nationality
* Headshot
* Right to work (visa)
* Email Address
* Phone Number (Including country code, e.g., AU)
* Website (Type, Url)
* Location
* Preferred Work Location
* Willing to Relocate
* Availability
* Objective
* Summary
* Achievements
* Associations
* Hobby
* Job Title
* Mapped to default taxonomies (optional)
* Standard Occupation Classifications provided
* Organization
* Location
* Dates
* Description
* Type (e.g. fulltime, volunteer, intern)
* Accreditation
* Level
* incl. Certifications & Conferences
* Organization
* Location
* Major
* Minor
* Dates
* Grade
* incl. Score & Unit
* Title
* Description
* Dates
* Organization
* Type (e.g. Professional or Education)
* Language
* incl. Proficiency
* Skills
* Mapped to multiple default taxonomies (optional)
* Title
* Dates
* Journal Name
* Patent Name
* Referee Name
* Contact Details
* Organization
## Sample Output
The following is an example 'compact' data object returned for a resume in the API response. A compact data response returns only the 'parsed' values and not the 'raw' text and any additional metadata.
```expandable theme={null}
{
"data": {
"achievement": null,
"association": null,
"availability": null,
"candidateName": {
"candidateNameFamily": "Christensen",
"candidateNameFirst": "Hugo"
},
"dateOfBirth": null,
"education": [
{
"educationDateRange": "09/2001 - 7/2005",
"educationLocation": {
"formatted": "Melbourne VIC, Australia",
"streetNumber": null,
"street": null,
"apartmentNumber": null,
"city": "Melbourne",
"postalCode": null,
"state": "Victoria",
"country": "Australia",
"rawInput": "Melbourne, VIC",
"countryCode": "AU",
"latitude": -37.8136276,
"longitude": 144.9630576,
"poBox": null
},
"educationAccreditation": "BS",
"educationOrganization": "Monash University",
"educationMajor": [
"Computer science and technology"
],
"educationLevel": {
"id": 7871,
"label": "Bachelor",
"value": "Bachelor"
}
},
{
"educationAccreditation": "Project Management Professional (PMP)",
"educationOrganization": "PMI",
"educationDateRange": "June 2017",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationAccreditation": "Certified ScrumMaster (CSM)",
"educationOrganization": "Scrum Alliance",
"educationDateRange": "June 2017",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationOrganization": "Ulead System Company",
"educationAccreditation": "C+ +, and MFC",
"educationDateRange": "2005",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationAccreditation": "IBM Portal and WCM training",
"educationOrganization": "IBM",
"educationDateRange": "201",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationAccreditation": "Platform Architecture and Design training program",
"educationOrganization": "BOM Design University",
"educationDateRange": "201",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationAccreditation": "Interfunctional Communication Skills",
"educationOrganization": "51Job",
"educationDateRange": "201",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationAccreditation": "New Ways of Leading",
"educationOrganization": "BOM Vendor",
"educationDateRange": "2016",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
},
{
"educationOrganization": "BOM Vendor",
"educationAccreditation": "PMS – Managing Poor performance and unacceptable behavior",
"educationDateRange": "201",
"educationLevel": {
"id": 8313,
"label": "Course/Certificate",
"value": "Course/Certificate"
}
}
],
"email": [
"hhchristensen@outlook.com"
],
"headshot": null,
"hobby": null,
"language": null,
"location": null,
"nationality": null,
"objective": null,
"patent": null,
"phoneNumber": [
"0458 023 928"
],
"preferredWorkLocation": null,
"project": null,
"publication": null,
"referee": null,
"rightToWork": null,
"skill": [
"AngularJS",
"React",
"Application",
"RESTful",
"programming",
"Object",
"Analysis",
"SDLC",
"logical",
"programing skills.",
"Self-Motivated",
"Self-Starter",
"Team",
"supervision",
"Communication skills",
"CDN)",
"MS SQL Server",
"bootstrap",
"website analytics",
"SEO",
"AWS",
"MS access",
"Data layer O/R Mapping (Subsonic",
"LLBLGen",
"Linq2Entities)",
"In-memory data cache (Redis)",
"Crystal",
"Organizational skills",
"Time management skills.",
"Programming",
"C#",
".NET Framework",
"JavaScript",
"C+ +",
"MFC",
"Delphi 5",
"VB 6.0",
"Web Technologies",
"HTML",
"JavaScript/AJAX",
"Bootstrap",
"AngularJS",
"Website performance tuning",
"Website analytics",
"A/B test",
"SEO",
"Web application configurations (IIS",
"domain redirect",
"load balance",
"SQL Performance tuning",
"Complicated Stored procedure",
"function",
"Active Reports",
"SQL Server Reporting Service",
"Crystal Reports",
"ASP.NET",
"ADO.NET",
"Web Services",
"Windows Services",
"WCF",
"Visual Studio",
"2003/2005/2008/2010/2015",
"Version Control Tools",
"SVN",
"GIT",
"TFS",
"Visual Source Safe (VSS)",
"Web Content Manager (WCM)",
"AEM",
"Visio",
"Visual Paradigm",
"Power Designer",
"Bugzilla",
"RTC",
"JIRA",
"Confluence",
"ASP.NET",
"GIT;",
"Website performance tuning",
"CDN",
"Load balance",
"SEO"
],
"summary": {},
"totalYearsExperience": null,
"website": null,
"willingToRelocate": null,
"workExperience": [
{
"workExperienceDateRange": "01/2014 – Now",
"workExperienceOrganization": "Bank of Melbourne",
"jobTitle": "Technical Leader, Online Solution team",
"jobDescription": {},
"workExperienceType": {
"id": 7874,
"label": "Full time",
"value": "Full time"
}
},
{
"workExperienceDateRange": "11/2011 – 12/2013",
"workExperienceOrganization": "PEPPERMAYO",
"jobTitle": "Sr. eCommence Website Developer",
"jobDescription": {},
"workExperienceType": {
"id": 7874,
"label": "Full time",
"value": "Full time"
}
},
{
"workExperienceDateRange": "01/2008 – 08/2010",
"workExperienceOrganization": "Accelx Software Solutions",
"jobTitle": "Sr. .NET Developer, EMC Journaling",
"jobDescription": {},
"workExperienceType": {
"id": 7874,
"label": "Full time",
"value": "Full time"
}
}
],
"rawText": "Resume Hugo Christensen Tel: 0458 023 928 Email: hhchristensen@outlook.com SUMMARY: ➢ Technical leader currently with BOM Company (Bank of Melbourne). Responsible for leading the offshore team to maintain and enhance the website of BOM.com. Including the responsive design with bootstrap, rapid online forms and loan calculators, interest rates, website analytics and SEO ➢ Microsoft Technology Professional with 1 1 years of hands-on experience in analysis, designing, coding and testing of web applications ➢ Experienced in developing large scale e-commerce application with ASP. NET MVC, social network application with AWS, and other web applications with ASP.NET/SQL Server technologies ➢ Experienced in developing financial open systems such as credit card and merchants management system, post transaction systems for generation audit reports and customer letters ➢ Experienced in data modeling, database design, programming of stored procedures, functions, triggers, and cursors using Transact-SQL. Experienced in migration business application from Oracle to SQL Server and knowledge of MongoDB ➢ Experienced in web-based reporting with SQL Server Reporting Service, Active Reports and Crystal Report ➢ Experienced in performance tuning of large scale e-commerce website from both front-end and backend with different technologies, including but not limited to reduce http requests, combine and minify multiple CSS/JS files, CSS sprite, lazy load images, partial page caching, memory cache with Redis, preloaded data for page rendering, and leverage of CDN ➢ Experienced in JavaScript programming skills such as JQuery, AJAX, Bootstrap. Knowledge of AngularJS and React Native ➢ Experienced in Windows Service Application and RESTful Services with C# .Net Framework. Experienced in developing batch jobs of file generation and importing across different bank systems communication ➢ Experienced in n-tier enterprise web application development. Strong knowledge with Object Oriented programming (OOPS), Object Oriented Analysis and Design (OOAD). Knowledge of .NET best practices and design patterns, such as SOLID principles, design patterns like Factory, Adapter, Proxy, Observer, and IoC etc. ➢ Experienced in production support with strong technical research capability, including problem analysis and urgent incident fix ➢ Experienced in software development process with both agile (scrum) and waterfall SDLC including requirements analysis, design, implementation, testing and deployment of large scale web application ➢ Excellent analytical, logical and programing skills. Self-Motivated, Self-Starter, Team Player can work with minimal supervision with effective Communication skills and Organizational skills combined with attention and Time management skills. TECHNI CAL SKI LLS: ➢ Programming Languages: C# and .NET Framework, JavaScript, C+ + and MFC, Delphi 5, VB 6.0 ➢ Web Technologies: HTML, JavaScript/AJAX, Bootstrap, AngularJS, Website performance tuning, Website analytics, A/B test, SEO, Web application configurations (IIS, domain redirect, load balance, CDN) ➢ Database Technologies: MS SQL Server, MS access, Data layer O/R Mapping (Subsonic, LLBLGen, Linq2Entities), In-memory data cache (Redis), SQL Performance tuning, Complicated Stored procedure and function ➢ Reporting Tools: Active Reports, SQL Server Reporting Service, Crystal Reports ➢ .NET Technologies: ASP.NET, ADO.NET, Web Services, Windows Services, WCF, Visual Studio 2003/2005/2008/2010/2015 ➢ Version Control Tools: SVN, GIT, TFS, Visual Source Safe (VSS) ➢ Other Packages/Tools: Web Content Manager (WCM), AEM, Visio, Visual Paradigm, Power Designer, Bugzilla, RTC, JIRA, Confluence PROFESSI ONAL EXPERI ENCE: Bank of Melbourne 01/2014 – Now Technical Leader, Online Solution team Description: The team maintains and enhances multiple web sites and applications in BOM. Including BOM.com website maintenance and enhancement, SG EPATs web application, China Inc. SharePoint intranet site, and the other systems like Rapid Online Forms backend, eAdmin Interest Rates. Responsibilities: Lead developer team to design and implement the business requirements, to cooperate with the onshore teams in Singapore and Melbourne. Responsible for communication, coordination and management of the offshore team in Chengdu. Lead the technical transition from WCM to AEM (Adobe Experience Manager), responsive design with bootstrap, and site analytics. Technologies: IBM WCM; AEM; Website analytics; Test & Target; SEO; Responsive design, bootstrap; MS.Net, C#, SQL Server, SSRS; Radware, Akamai, AWS; change management and production support. PEPPERMAYO 11/2011 – 12/2013 Sr. eCommence Website Developer, Peppermayo.com Description: PEPPERMAYO started in 2007 as a specialty fashion e-retailer, and has become a leading apparel brand in Australia. PEPPERMAYO has more than tens of millions registered users; and yearly sales was around 3 billion in 2012. Responsibilities: Implemented web application according to business requirements. Improved performance from the client side with different technologies; Include lazy load, CSS Sprite, http requests reduction, combine minify and compress CSS/JavaScript. Implemented the controller layer of the web application with MVC architecture. Encapsulated interfaces and data access layer. Used different technologies to improve the server side performance including output cache, Redis, and preloaded data for page rendering. After performance tuning from both client side and server side, the server side response time (TP999) was less than 700ms; client side average load time was less than 2300ms. We had cut down 37% servers (Web + DB) and network traffic decreased by 41% . Technologies: C# .NET Framework; ASP.NET MVC; GIT; Website performance tuning, CDN, Load balance, SEO Accelx Software Solutions 01/2008 – 08/2010 Sr. .NET Developer, EMC Journaling Description: EMC Journaling is a user-transparent addition of EMC solutions. It saves content in EMC DCTM instead of MS SQL Server; and access \"native\" in SharePoint. Responsibilities: Implemented Edrsadm (a command-line backup tool) for Journaling Database. Implemented CRSS (content recovery staging system). Implement templates for various admin configuration pages. Technologies: C# .NET Framework; SQL Server 2005; Perforce; Fisheye ; JIRA; EMC DCTM; SharePoint 2007 EDUCATI ON: BS Monash University – Melbourne, VIC 09/2001 - 7/2005 Major: Computer science and technology CERTI FI CATES: Certificate Name Month/Year Authority Project Management Professional (PMP) June 2017 PMI Certified ScrumMaster (CSM) June 2017 Scrum Alliance TRAI NI NGS: Training Name Year Trainer C+ +, and MFC 2005 Ulead System Company IBM Portal and WCM training 201 4 IBM Platform Architecture and Design training program 201 4 BOM Design University Interfunctional Communication Skills 201 5 51Job New Ways of Leading 2016 BOM Vendor PMS – Managing Poor performance and unacceptable behavior 201 7 BOM Vendor"
}
```
# Getting started with Affinda recruitment products
Source: https://docs.affinda.com/resumes/getting-started
Introduction to Affinda's recruitment products, including the Resume Parser, Job Description Parser, Resume Redactor, Resume Summary, and Search & Match.
## Recruitment Technology Product Suite
Affinda's product suite for Recruitment Technology covers five complementary pre-built offerings. These products leverage our core technology and the data extracted from our industry-leading Resume Parser to deliver time-saving products to the recruitment industry.
If you are looking to automate the extraction from other document types or need a custom resume parser, see [**Information Extraction Models**](/configuration/extraction-models)**.**
## Getting Started
After [creating your free trial](https://www.affinda.com/guest) and selecting 'Resume Parsing' as your use case, a Workspace specific to recruitment technology will be configured that contains all products in the suite for testing. This Workspace will be configured with:
* **Classification disabled:** Typically, Resume Parsing customers will know the document type they are processing, so they should upload directly to the Document Type (rather than to the Workspace and relying on Affinda classification). This will improve the speed and accuracy of parsing.
* **Validation disabled:** Disabling validation hides features (e.g. 'Confirm Document') that are typically used where there is a 'human in the loop' required to process documents.
The above settings can be enabled via Workflow settings.
## Testing
### Understanding the Affinda document interface
Affinda's document interface provides a simple tool to visualise all of the outputs from the model. This means that customers can quickly assess the accuracy of the solution and all of the data that has been extracted. Customers can observe the raw values that have been extracted from the document, as well as the final 'parsed' values that have been formatted or mapped into standardised values that can be more easily used in downstream processing.
### Updating visible fields
When first getting started, all fields extracted will be visible. However, often customers will only care about a subset of fields that Affinda extracts from resumes. To enhance the testing process, customers can 'disable' certain fields in our document interface by selecting 'Configure Fields' when viewing a document. These fields are then no longer visible in the user interface, so testing is restricted just to the fields that matter.
### Additional data available in API response
While the Affinda document interface includes a wide range of data and provides a clear representation of model accuracy, additional data is available within the API response. This includes a wide range of metadata and both the raw and parsed values.
For the Resume Parser, additional data about specific fields not visible in the UI is also present, including Standard Occupation Classifications, structured location information, and additional details on websites, phone numbers, and other contact information. (See [Data Extracted](/resumes/data-extracted) for an example output.)
We recommend that customers familiarise themselves with all of the data present in the API response as part of testing.
### Inviting colleagues
For information on how to add colleagues to assist with testing, see [**User Management**](/configuration/user-management)**.**
# Index candidate and job data for search
Source: https://docs.affinda.com/resumes/indexing-data
Add candidates and jobs to an Affinda index so the data is available for Search & Match queries, including index management and update operations.
Affinda's Search & Match solution is designed to search across one or more 'indices'. These indices contain the data that is relevant for searching quickly and efficiently through thousands of candidates or job records.
Customers can create as many indices as they wish and enable a search to be made across their entire database, or just a subset of the relevant candidate or job set. For example, customers may wish to create a new index that reflects each job type, candidate location, or recruitment consultant.
During the free trial phase, uploaded resumes and jobs are automatically added to a single index for testing purposes. This feature is not available in a paid plan, and indexing must be managed programmatically.
## Process for indexing data
Indexing data is managed programmatically via the Affinda API. There is a simple process to follow to create indices that are then easily searchable using the Affinda Search & Match solution.
1. [Create a new index](https://docs.affinda.com/api-reference/search-&-match/create-a-new-index)
2. [Add data to index](https://docs.affinda.com/api-reference/search-&-match/index-a-new-document)
Note, to index data from your existing database, first create the resume record in our system by uploading the resume for parsing using the API using the 'data' method ([see here for more information](/resumes/add-candidate-data)) and then indexing using the unique identifier returned.
Each index will have a unique identifier associated with it that users must then specify when searching.
# Integrate Affinda's Resume Parser
Source: https://docs.affinda.com/resumes/integration
Integrate Affinda's Resume Parser into your ATS, recruitment platform, or HR system using the API, webhooks, and client libraries with code examples.
Parsing resumes and job descriptions using Affinda is easy using Affinda's simple and flexible REST API. Our [API Reference](/reference/getting-started) provides all the required information to start processing documents programmatically. The guide below provides information that is specific to Recruitment Technology to make it even easier.
## Uploading documents
To make your first API call, you'll need to:
1. **Generate an API key** (*Settings* → *API Keys*)
2. **Retrieve the Workspace identifier** (*Workspace* -> *Workflow* -> *Integrations*)
3. **Retrieve the relevant Document Type identifier** (Document Types -> Resume Parser (or other Document Type) -> Settings)
```bash cURL theme={null}
# 1. Set your API key (found in the Affinda dashboard)
export AFFINDA_API_KEY="aff_562..."
# 2. Upload a document and wait for processing to finish
curl -X POST https://api.affinda.com/v3/documents \
-H "Authorization: Bearer $AFFINDA_API_KEY" \
-F "file=@sample_invoice.pdf" \
-F "workspace=YOUR_WORKSPACE_IDENTIFIER"
-F "documentType"=YOUR_DOCUMENT_TYPE_IDENTIFIER
```
```python Python theme={null}
# !pip install affinda
from pathlib import Path
from affinda import AffindaAPI, TokenCredential
API_KEY = "YOUR_API_KEY" # replace with your actual key
WORKSPACE_ID = "YOUR_WORKSPACE_IDENTIFIER" # e.g. "vBAdDBer"
DOCUMENT_TYPE_ID = "YOUR_DOCUMENT_TYPE_IDENTIFIER"
FILE_PATH = Path("resume.pdf") # path to the résumé you want to parse
# Set up the client
credential = TokenCredential(token=API_KEY)
client = AffindaAPI(credential=credential)
# Upload the document and wait until processing finishes
with FILE_PATH.open("rb") as f:
doc = client.create_document(
file=f,
workspace=WORKSPACE_ID,
documentType=DOCUMENT_TYPE_ID,
)
# Access parsed data
print(doc.data)
```
```javascript Node.js theme={null}
import { AffindaAPI, AffindaCredential } from "@affinda/affinda";
import * as fs from "fs";
const credential = new AffindaCredential("YOUR_API_KEY");
const client = new AffindaAPI(credential);
const file = fs.createReadStream("resume.pdf");
client
.createDocument({
file,
workspace: "YOUR_WORKSPACE_IDENTIFIER",
documentType: "YOUR_DOCUMENT_TYPE_IDENTIFIER"
})
.then(doc => {
console.log("Parsed data:", doc.data);
})
.catch(err => console.error("Error:", err));
```
### Optional parameters
The above sample will allow users to upload a document using our default settings. However, users may wish to consider the use of other parameters when setting up their integrations.
The below are commonly used parameters for the Resume Parsing use case. For the full list of parameters, see [Uploading Documents](/reference/upload-options).
**Synchronous vs. Asynchronous responses**
Customers can set `wait` to true / false depending if the parsing response needs to be returned synchronously or not.
* **True:** Response will be returned once parsing has completed and will include extracted data
* **False:** Response will be returned immediately with \_meta \_object only (which includes the unique identifier assigned to that document). Extracted data will need to be requested later (either through polling or [webhooks](/reference/webhooks)). Recommended for customers who are bulk uploading.
The default is true (synchronous parsing).
**Document Deletion**
For customers who do not wish to store their documents, options are available:
* **expiryTime:** Document will be automatically deleted at this time
* **deleteAfterParse:** No data is stored, and the document is deleted as soon as it is parsed
**Compact**
By default, the Affinda API will return the full JSON response with associated metadata for each field. To reduce the amount of information in the data object, customers can choose to enable `compact` to return only the parsed value.
**Parsing Time**
For customers where speed of response is a key consideration, additional improvements can be achieved when uploading via API by setting the following parameters:
* **wait:** True
* **enableValidationTool:** False
* **deleteAfterParse:** True
* **compact:** True
**Search & Match integration**
For information about integrating Affinda's Search & Match product, contact Affinda for more details.
# Job Description Parser fields and capabilities
Source: https://docs.affinda.com/resumes/job-description-parser
Overview of Affinda's Job Description Parser, including the list of fields extracted from job postings such as title, requirements, skills, and salary.
Affinda's Job Description Parser uses the same technology as our Resume Parser to deliver similar data and similarly high accuracy. Typically, the Job Description Parser is used in conjunction with the Search & Match solution to match candidates to jobs; however, it can be used standalone.
## Data extracted
* Organization
* Location
* Job Title
* Occupation Classification
* Management Level
* Job Type (e.g. Full Time, Part Time, Casual)
* Start Date
* Remuneration
* Years Experience Required
* Languages Required
* Skills (mapped to a detailed best-in-class taxonomy containing over 3,000 soft and hard skills)
* Education Level Required
* Education Accreditation
* Certifications
* Job Contact Details (Name, Phone Number)
### **Sample output**
The following is an example data object returned for a Job description in the API response:
```expandable theme={null}
"data": {
"jobTitle": {
"id": 560,
"rectangle": {
"x0": 71.6,
"y0": 72.996704,
"x1": 202.85599,
"y1": 82.0567
},
"rectangles": [
{
"x0": 71.6,
"y0": 72.996704,
"x1": 98.084,
"y1": 82.0567
},
{
"x0": 103.58,
"y0": 72.996704,
"x1": 202.85599,
"y1": 82.0567
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "CAR DEVELOPMENT",
"parsed": {
"name": "Car Cleaner",
"emsiId": "ET97CBE9A3D491FAB9",
"classification": {
"socCode": 9226,
"title": "Vehicle valeters and cleaners",
"minorGroup": "Elementary Cleaning Occupations",
"subMajorGroup": "ELEMENTARY ADMINISTRATION AND SERVICE OCCUPATIONS",
"majorGroup": "ELEMENTARY OCCUPATIONS"
},
"managementLevel": null
},
"confidence": 0.863,
"classificationConfidence": 0.863,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "RuhhBiYX",
"contentType": "enum"
},
"contactEmail": {
"id": 648,
"rectangle": {
"x0": 20.47284,
"y0": 568.8678,
"x1": 163.06152,
"y1": 578.0729
},
"rectangles": [
{
"x0": 20.47284,
"y0": 568.8678,
"x1": 163.06152,
"y1": 578.0729
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "car.deals@cars.com",
"parsed": "car.deals@cars.com",
"confidence": 0.898,
"classificationConfidence": 0.898,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "KABywHCn",
"contentType": "text"
},
"contactName": {
"id": 645,
"rectangle": {
"x0": 20.835,
"y0": 548.27997,
"x1": 94.929,
"y1": 556.9199
},
"rectangles": [
{
"x0": 20.835,
"y0": 548.27997,
"x1": 94.929,
"y1": 556.9199
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "Carlos Naumore",
"parsed": "Carlos Naumore",
"confidence": 0.503,
"classificationConfidence": 0.503,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "mAHHqwep",
"contentType": "text"
},
"contactPhone": {
"id": 642,
"rectangle": {
"x0": 34.959,
"y0": 294.472,
"x1": 117.56999,
"y1": 301.27594
},
"rectangles": [
{
"x0": 34.959,
"y0": 294.472,
"x1": 117.56999,
"y1": 301.27594
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "+12370544579",
"parsed": "+12370544579",
"confidence": 0.515,
"classificationConfidence": 0.515,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "FzScnopb",
"contentType": "text"
},
"startDate": {
"id": 681,
"rectangle": {
"x0": 428.22498,
"y0": 392.03998,
"x1": 453.722,
"y1": 399.00598
},
"rectangles": [
{
"x0": 428.22498,
"y0": 392.03998,
"x1": 453.722,
"y1": 399.00598
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "Juillet",
"parsed": "2023-07-01",
"confidence": 0.242,
"classificationConfidence": 0.242,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "YTcJSdTZ",
"contentType": "date"
},
"endDate": {
"id": 675,
"rectangle": {
"x0": 531.88605,
"y0": 312.162,
"x1": 576.904,
"y1": 318.96594
},
"rectangles": [
{
"x0": 531.88605,
"y0": 312.162,
"x1": 576.904,
"y1": 318.96594
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "Mars 2021",
"parsed": "2021-03-01",
"confidence": 0.345,
"classificationConfidence": 0.345,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "zijHudLq",
"contentType": "date"
},
"jobType": {
"id": 562,
"rectangle": {
"x0": 142.728,
"y0": 141.56067,
"x1": 188.07047,
"y1": 148.5177
},
"rectangles": [
{
"x0": 142.728,
"y0": 141.56067,
"x1": 188.07047,
"y1": 148.5177
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "Full-time",
"parsed": "Full time",
"confidence": 0.78,
"classificationConfidence": 0.78,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "LhPPiuDQ",
"contentType": "text"
},
"languages": [
{
"id": 644,
"rectangle": {
"x0": 21.411,
"y0": 476.97037,
"x1": 58.99008,
"y1": 486.59174
},
"rectangles": [
{
"x0": 21.411,
"y0": 476.97037,
"x1": 58.99008,
"y1": 486.59174
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "Français",
"parsed": null,
"confidence": 0.764,
"classificationConfidence": 0.764,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "NTSRSjSL",
"contentType": "enum"
}
],
"skills": [
{
"id": 573,
"rectangle": {
"x0": 129.21,
"y0": 490.6007,
"x1": 478.88046,
"y1": 500.27072
},
"rectangles": [
{
"x0": 129.21,
"y0": 490.6007,
"x1": 478.88046,
"y1": 500.27072
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "Manufacutring process selection, metelurgy expeirence, crash testing",
"parsed": "Crash Testing",
"confidence": 0.957,
"classificationConfidence": 0.957,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "BorLGmtj",
"contentType": "enum"
}
],
"organizationName": {
"id": 576,
"rectangle": {
"x0": 18.891,
"y0": 80.34149,
"x1": 158.78491,
"y1": 93.544495
},
"rectangles": [
{
"x0": 18.891,
"y0": 80.34149,
"x1": 158.78491,
"y1": 93.544495
}
],
"document": "pIFbXYBW",
"pageIndex": 0,
"raw": "Car Company Pty Ltd",
"parsed": "Car Company Pty Ltd",
"confidence": 0.893,
"classificationConfidence": 0.893,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "CMWfifnu",
"contentType": "text"
},
"organizationWebsite": {
"id": 640,
"rectangle": {
"x0": 34.626,
"y0": 199.0299,
"x1": 114.05101,
"y1": 207.66992
},
"rectangles": [
{
"x0": 34.626,
"y0": 199.0299,
"x1": 114.05101,
"y1": 207.66992
}
],
"document": "HKjwxUPH",
"pageIndex": 0,
"raw": "cardeal.com",
"parsed": "cardeal.com",
"confidence": 0.418,
"classificationConfidence": 0.418,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "xUrAXGYG",
"contentType": "text"
},
"educationLevel": {
"id": 568,
"rectangle": {
"x0": 78.77,
"y0": 387.80072,
"x1": 131.07053,
"y1": 395.53073
},
"rectangles": [
{
"x0": 78.77,
"y0": 387.80072,
"x1": 131.07053,
"y1": 395.53073
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "Bachelor's",
"parsed": "bachelors",
"confidence": 0.6,
"classificationConfidence": 0.6,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "clWOADvM",
"contentType": "text"
},
"educationAccreditation": {
"id": 569,
"rectangle": {
"x0": 147.01,
"y0": 387.80072,
"x1": 206.5305,
"y1": 397.47073
},
"rectangles": [
{
"x0": 147.01,
"y0": 387.80072,
"x1": 206.5305,
"y1": 397.47073
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "Engineering",
"parsed": "Engineering",
"confidence": 0.538,
"classificationConfidence": 0.538,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "FGbphvmO",
"contentType": "text"
},
"expectedRemuneration": {
"id": 598,
"rectangle": {
"x0": 361.17,
"y0": 430.6725,
"x1": 585.858,
"y1": 450.6525
},
"rectangles": [
{
"x0": 361.17,
"y0": 430.6725,
"x1": 585.858,
"y1": 450.6525
}
],
"document": "bFLidYbM",
"pageIndex": 0,
"raw": "$10,000 to $18,000Monthly",
"parsed": {
"minimum": 10000.0,
"maximum": 18000.0,
"currency": "USD",
"unit": "Monthly"
},
"confidence": 0.673,
"classificationConfidence": 0.673,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "hLpbKXXF",
"contentType": "text"
},
"location": {
"id": 563,
"rectangle": {
"x0": 148.245,
"y0": 180.06067,
"x1": 216.711,
"y1": 188.8357
},
"rectangles": [
{
"x0": 148.245,
"y0": 180.06067,
"x1": 190.61377,
"y1": 188.8357
},
{
"x0": 195.04065,
"y0": 180.22272,
"x1": 216.711,
"y1": 187.0177
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "Virginia, USA",
"parsed": {
"formatted": "Virginia, USA",
"streetNumber": null,
"street": null,
"apartmentNumber": null,
"city": null,
"postalCode": null,
"state": "Virginia",
"country": "United States",
"rawInput": "Virginia, USA",
"countryCode": "US",
"latitude": 37.4315734,
"longitude": -78.6568942
},
"confidence": 0.85,
"classificationConfidence": 0.85,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "RwZyHkaG",
"contentType": "location"
},
"certifications": [
{
"id": 590,
"rectangle": {
"x0": 168.89325,
"y0": 688.998,
"x1": 489.00113,
"y1": 700.734
},
"rectangles": [
{
"x0": 168.89325,
"y0": 688.998,
"x1": 489.00113,
"y1": 700.734
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "licence to operate an Elevating Work Platform (EWP)",
"parsed": "licence to operate an Elevating Work Platform (EWP)",
"confidence": 0.841,
"classificationConfidence": 0.841,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "ebEGNPCy",
"contentType": "text"
}
],
"yearsExperience": {
"id": 571,
"rectangle": {
"x0": 78.77,
"y0": 431.7007,
"x1": 382.3356,
"y1": 441.37073
},
"rectangles": [
{
"x0": 78.77,
"y0": 431.7007,
"x1": 382.3356,
"y1": 441.37073
}
],
"document": "PzFmpBJZ",
"pageIndex": 0,
"raw": "Minimum of one year's experience in the automtive industry",
"parsed": {
"minimum": 1,
"maximum": null
},
"confidence": 0.695,
"classificationConfidence": 0.695,
"textExtractionConfidence": 1.0,
"isVerified": false,
"isClientVerified": false,
"isAutoVerified": false,
"dataPoint": "VIpUXkyw",
"contentType": "json"
},
"rawText": "Car Cleaner ..."
}
```
# Resume Redactor for unbiased recruitment
Source: https://docs.affinda.com/resumes/resume-redactor
How Affinda's Resume Redactor removes personal and demographic data from resumes to support unbiased recruitment, including the list of redactable fields.
Affinda's Resume Redactor can be used to redact a wide range of data for a range of benefits:
* **Protect against discriminatory biases**: Reduce bias against age, gender, etc.
* **Promote fair candidate selection**: Highlight skills and experience rather than background
* **Foster increased diversity**: Build teams with broader views and perspectives
* **Retain client contact details:** Recruiters can share resumes with their end-customers without sharing names and identifying details
While the Resume Redactor uses similar technology to Affinda's Resume Parser, it is configured differently to ensure that no data is left unredacted.
* Bias towards overpredicting
* Every instance of a particular field or word (e.g. candidate name, location) is redacted
Resume Redactor also works well with Cover Letters
## Exporting the redacted file
To test the output of the Resume Redactor, users can download directly from the web application by selecting the option under the '...' menu.
## Fields redacted
* Candidate Name
* Candidate Phone Number
* Candidate email
* Headshot
* Date Of Birth
* Personal Location
* Gender/Pronouns
* Nationality/Ethnicity
* Marital Status
* Age
* Personal Website
* Education Organisation
* Education Location
* Education Dates
* Education Website
* Work Organisation
* Work Location
* Work Dates
* Work Websites
* Activity Organisation Name
* Activity Location
* Activity Dates
* Activity Website
* Referee Name
* Referee Position
* Referee Organisation Name
* Referee Email
* Referee Phone Number
Any fields that you do not want to be redacted can be disabled in Document Type settings
## Exporting redacted files
Within the Affinda Platform, users will see the predicted values as with other document types. Fields will not yet be redacted. To export a redacted version of the resume, use the [redact document endpoint](https://docs.affinda.com/api-reference/documents/get-redacted-document).
# AI-generated candidate summaries from resumes
Source: https://docs.affinda.com/resumes/resume-summary
Generate AI-powered candidate summaries from parsed resumes with Affinda Resume Summary, including configuration options and supported output formats.
Our Resume Summary product streamlines the hiring process by automatically generating concise overviews of candidates' experience, skills, and qualifications directly from their resumes. The tool helps hiring teams quickly assess applicants without manually reviewing lengthy resumes
Designed for global hiring, the summary is available in the same language as the resume, ensuring the product is suitable for customers in all regions. Personal details such as names, ages, and nationalities are excluded to support fair and unbiased recruitment, allowing hiring teams to focus solely on candidates’ qualifications and job fit.
## Key benefits
**Faster Hiring Decisions**\
Instantly access key candidate insights without sifting through full resumes.
**Improved Selection Process**\
Focus on relevant skills and experience to identify top candidates efficiently.
**Fair & Unbiased Screening**\
Automatically removes personal identifiers, ensuring assessments are based purely on qualifications.
**Scalability for High-Volume Hiring**\
Handle large application volumes effortlessly, making it ideal for growing businesses and peak hiring periods.
## Customising the summary
If you’d like to tailor your summary—such as focusing only on skills, education, or adjusting the summary length—please contact Affinda.
# Self-hosted deployment for Resume Parser
Source: https://docs.affinda.com/resumes/self-hosted
Run Affinda's Resume Parser in a self-hosted or on-premises deployment, including infrastructure requirements, licensing, and operational considerations.
Most customers benefit from Affinda's technology through our hosted solution. However, some may require a locally deployed solution for specific needs. To support these users, we’ve published an [Affinda Self-Hosted Deployment Guide](https://github.com/affinda/self-hosted).
Self-hosted deployment is currently available for Resume and Job Description Parsing.
If you’re interested in a local deployment, please contact Affinda for further details.
# Resume Parser taxonomies for standardized fields
Source: https://docs.affinda.com/resumes/taxonomies
Affinda's Resume Parser uses pre-built taxonomies to standardize key fields like skills, making data more accurate and consistent across your systems.
These taxonomies work with resumes in any language by mapping values to a single, shared framework. This eliminates the hassle of cleaning and normalizing data, making it easier to analyze, report, and integrate into other processes.
## Configurable Taxonomies
To change the taxonomy from the default setting noted below, get in touch with Affinda.
### Skills
* [Lightcast](https://lightcast.io/)
* [**ESCO**](https://esco.ec.europa.eu/en/classification/skill_main)
This Lightcast skills taxonomy works across all 50+ languages providing standardised data using a best-in-class taxonomy. By default, mapped skills are returned in English. We can return mapped values in the original resume's language. To enable this, please get in contact with Affinda.
### **Job titles**
By default, the NextGen Resume Parser does not map job titles to any taxonomy and returns only the extracted raw string; however, Affinda can configure the following taxonomies on your account:
* [Lightcast](https://lightcast.io/)
* [ESCO](https://esco.ec.europa.eu/en/classification/skill_main)
### **Occupation Classification**
* [UK SOC Standard Occupational Classification](https://www.ons.gov.uk/methodology/classificationsandstandards/standardoccupationalclassificationsoc)
* [ISCO](https://www.ilo.org/public/english/bureau/stat/isco/)
* [O\*NET](https://www.onetcenter.org/taxonomy.html)
All three Occupation Classifications are available in the API response automatically.
# Affinda system status and uptime
Source: https://docs.affinda.com/status
Check the live status of Affinda services, view incident history, scheduled maintenance windows, and uptime reports for the platform and API.
# Get support from Affinda
Source: https://docs.affinda.com/support
How to get help with the Affinda platform: use the in-app Affinda Agent for product and integration questions, or email support@affinda.com to lodge a ticket.
There are two ways to get help with Affinda, depending on what you need.
## Ask the Affinda Agent
For most product-related questions and integration assistance, the **Affinda Agent** built into the app is the fastest way to get answers.
The Agent can help you:
* Answer questions about platform features, configuration, and best practices
* Walk you through setting up extraction models, workflows, and validation rules
* Assist with building integrations and connecting Affinda to your downstream systems
* Troubleshoot common issues with documents, fields, and exports
You'll find the Agent in the bottom-right corner of the [Affinda app](https://app.affinda.com).
## Email support
For anything the Agent can't resolve — including account issues, billing queries, bug reports, and other requests — lodge a ticket by emailing:
[**support@affinda.com**](mailto:support@affinda.com)
Please include as much detail as possible (workspace, document IDs, screenshots, and steps to reproduce) so our team can help you quickly.
# Trust center, security, and compliance
Source: https://docs.affinda.com/trust
Review Affinda's trust center for security policies, compliance certifications, data protection practices, and answers to common procurement questions.
# Affinda product updates and release notes
Source: https://docs.affinda.com/updates
Release notes for the Affinda platform, including new features, improvements, and bug fixes for extraction models, validation, integrations, and the API.
## Model performance dashboard
* New dashboard showing where human corrections are concentrated, so you can prioritise the configuration changes that give the biggest accuracy uplift
* Ranks document types and fields by correction volume, and splits corrections by issue type: missing fields, extra fields, wrong selection or location, and wrong value or cleanup
* Open any field to see the original prediction next to the reviewer's correction, and edit the field description from the same panel
* The **Model memory** tab ranks reference documents by the corrections made on documents that used them, flagging references with inaccurate annotations or a poor match to incoming documents
* Most useful for teams running human review as part of their day-to-day workflow
See [Model Performance](/configuration/model-performance) for more information.
### Usage graph: workspace and document type breakdowns
* The usage graph can now display usage broken down by workspace or by document type, in addition to the organization-level view
* Breakdown data populates from the release date onward; earlier usage is not back-populated into the breakdowns
See [Viewing usage by workspace or document type](/billing#viewing-usage-by-workspace-or-document-type) for more information.
### Built-in validators
* Affinda now supports built-in validators for a set of common standardized field types.
* To configure, simply navigate to your field, add a new validation rule, describe the validation check eg. "@ABNfield is a valid ABN" and click generate.
* Supported validators:
* `affinda.validators.abn` — ABN resolves to a current, active [Australian Business Register](https://abr.business.gov.au/) entity
* `affinda.validators.acn` — ACN ASIC checksum
* `affinda.validators.iban` — IBAN country format + MOD97 checksum
* `affinda.validators.bic` — BIC/SWIFT ISO 9362 syntax + country code
* `affinda.validators.vin_format` — VIN 17-character format
* `affinda.validators.vin_check_digit` — VIN format + check digit
* See [Validation Rules](/configuration/validation-rules#built-in-validators) for more information
### Consolidated usage endpoint
* New public endpoint (`GET /v3/usage`) that replaces the per-workspace and per-collection variants with a single call for org-, workspace-, and document-type-level reporting
* Returns **daily** credits consumption (previously monthly), scoped to an organization and optionally narrowed to a workspace or document type
* Uses current document type terminology and reports credits as a **single unified number** — no more `is_recruit` split, aligned with the rolling credit consolidation work
### Integrations: Export visibility improvements
* Added an **Archive on Success** setting that automatically archives documents once they've been successfully exported, keeping your active document list focused on items that still need attention
* Added a new filter at Workspace level to narrow the document list by **successful** or **failed** exports, making it easy to identify and action documents that didn't make it to the destination system
## Launch of Affinda Agent
* New AI-powered Affinda Agent guides users through onboarding and workspace setup using natural language
* Describe your use case — what documents you process, what data you need, and where it goes — and the agent configures your environment for you
* The agent can set up **Workspaces, Document Types, fields, validation rules** and other settings on your behalf, getting you to a working solution in minutes
* Designed to reduce the time and expertise required to go from sign-up to a fully configured document processing workflow
## AI Agent Integration Resource
* We've published a comprehensive integration resource designed specifically for AI coding agents (Cursor, Claude, Copilot, etc.)
* This single markdown file contains everything an agent needs to build an Affinda integration end-to-end: API basics, authentication, Python & TypeScript clients, structured outputs, webhooks, upload patterns, common errors, and a full map of our documentation
* **Two ways to use it:**
* **Direct link:** Ask your agent to read [https://docs.affinda.com/skill.md](https://docs.affinda.com/skill.md) before starting your integration
* **Persistent skill:** Install with `npx skills add affinda/skills` so your agent always has access
* This resource enables you to build a working integration without jumping across multiple documentation pages
## Selective page processing by document type
* You can now configure Affinda to process **only a continuous page range** from your documents, instead of processing every page by default.
* Page selection is defined **per document type**, giving you precise control over what gets processed and billed.
* Excluded pages are not processed and **are not charged**.
* Examples:
* **Invoices**: process only pages 1–3
* **Contracts**: process only pages 2–5
This feature is enabled by the Affinda team. Once configured, the rules are applied automatically during processing, with no changes required to your existing workflows.
For more information or to enable selective page processing, [contact the Affinda team.](https://www.affinda.com/contact)
## Updated Billing Page
* New billing page for customers paying in arrears, users can now see their month-to-date usage
## Improved App Location
* New users are now **automatically routed to the correct Affinda app instance** based on their location (AU/Global, EU, or US).
* The **sign-up form clearly shows which instance** users are creating an account in.
* Users who attempt to log in on the **wrong instance will see a banner** suggesting the correct one.
For more information, see [Deployment and Data Residency](https://docs.affinda.com/deployment-data-residency)
## New tables editor
* We have released a new tables experience that is faster and more intuitive for users
* **Grid mode:** a clean, predictable interface for classic column-based tables. Drag row/column lines directly on the page, select field names from header dropdowns, and see updates instantly.
* **Freeform for complex layouts:** annotate one example row and apply 'Fill Down' to handle irregular or stacked tables with far less effort.
* **Smart mode selection:** Affinda automatically detects whether a table should open in Grid or Freeform, with the option to switch manually at any time.
For more information, see our [Table Editor tutorial](/academy/table-editor).
## Classification-only document processing
* You can now process documents **for classification only**, skipping data extraction entirely
* This mode sharply cuts processing costs and reduces the number of credits used to a **maximum of 3 credits per document**, no matter the page count
* To enable this on a specific Document Type, get in touch with Affinda.
## Credit usage dashboard
* New dashboard showing credit usage over time added
* Dashboard can be accessed by Organization Owners and Admins
## Default maximum page limit raised to 20 pages
* The default page limit per document has been raised to 20 pages
* This limit can be raised on customer accounts if required - get in touch with Affinda to enable this
## User permissions updates
* Updates to permissions in web application to ensure that only pages relevant to user permission set is visible
* At least one Organization Owner must now be present at all times - users can not be removed or permission level downgraded if they are the only Owner
## Model Memory management
* Model Memory controls in workspace actions: add or remove confirmed documents without leaving the list view
* Do it one by one or use bulk actions to manage many at once
* Provides user's control over which documents shape model performance
## Filter by document attributes
* New filters by document attributes added to Document List view
* Filters added: Added Date, Added By, Confirmed, Confirmed By, Archived, In Model Memory, Split, Unclassified, Errored, Validation Passed, Validation Failed
* Quickly narrow your workspace views using recognisable details instead of wading through everything
## Duplicating Workspaces and Document Types
* Users can now duplicate a workspace and document types for faster configuration
* To duplicate a workspace, go to the workspace view, locate the three dots on the side of the workspace and select "duplicate"
* To duplicate a document type, go to the document type view, locate the three dots and select "duplicate"
## Workspace & Document Type Identifiers
* Identifiers required for API integration can now also be found in the Workspace or Document Type list by hitting the '...' next to the relevant item
## Integrations Agent (beta)
* Integrations agent enables users to build automated data export integrations with natural language instructions.
* The assistant uses Pipedream to connect Affinda with thousands of downstream applications.
* Access it by going to the Integrations tab in your organisation or through "Data Export" in your workspace settings.
* This feature is currently in beta and may undergo further improvements as we gather feedback
* See the [Affinda Agent integrations tutorial](/handbook/agent-integrations) for a step-by-step walkthrough, or the [Configure integrations with the Affinda Agent](/configuration/agent-integrations) page in the Configuration guide for more information
## New Affinda brand
* Affinda has launched an updated brand, providing a new look and feel for new and existing customers
* The Affinda Platform has been updated in line with this new brand
## Model Memory visibility
* Users can now more easily see which documents have been added to Model Memory by enabling this column in the document list view
## AI Assistant in Platform
* We’ve added a built-in AI assistant trained on all of Affinda’s product documentation.
* Click the Help button at the top of the page to open the assistant. From there, you can ask questions for technical details, configuration guidance and product features and best practices
## Organization Avatars
* The avatar for a newly created Organization will be auto-populated with the company logo where possible based on the domain of the user registering
## OCR Notifications
* Additional prompts added to document validation interface around OCR settings
* If a user selects an area on the document and no text is found (e.g. a supplier logo in an invoice), a prompt is flagged to the user to apply OCR to that document
* Admins are prompted to review [default OCR settings](/configuration/ocr) if they select 'Apply OCR' on a document
## Suggested Re-Parse Notification
* Now, users will see a notification in the **Document Validation view** when a document may benefit from being re-parsed. This can happen in two cases:
1. **A new, more relevant model memory document has been added** - meaning the system has learned from a better example and can now extract more accurate results. See [Model Memory](/configuration/model-memory) for more information.
2. **The document type configuration has been updated** - making the extraction on older documents out of date. Reparsing applies the latest changes to the document. See[ Field Configuration](/configuration/standard-fields) for more information.
* In either case, the **Re-parse button** in the top right corner of the document will turn **orange** to indicate action is needed.
## Self-Learning Data Sources
* Data Sources now include an option to **Remember selections**
* When enabled, the platform records the confirmed value for a given raw text extraction and automatically reuses that value the next time the same text appears in a new document
* This option is **enabled by default** for every new Data Source field
See [Picklists](/configuration/picklists) for more information.
## Embeddable Review URL
* The document validation interface can be embedded in downstream workflows with the release of our embeddable review URL to all users
* This feature was previously available only to existing customers using the legacy version of the platform
See [Embedded Mode](/reference/embedded) for more information.
## Number Data Type
* We have consolidated all number data types into a single field type
* Users can adjust the number of decimal places under 'Decimal Options'
See [Standard Field Types](/configuration/standard-fields) for more information.
## New Documentation Hub
We’ve launched a brand-new documentation experience to help you get the most out of the Affinda Platform—whether you’re just getting started or building advanced integrations.
* **Affinda Academy:** Step-by-step tutorials, from onboarding basics to advanced playbooks, so you can master the platform at your own pace.
* **Configuration Guide:** A comprehensive reference to configure Affinda for your exact use case and workflows.
* **API Reference:** Developer-friendly documentation to get your integration up and running fast.
* **Resume Parsing Guide:** Tailored resources for customers using our Resume Parser and related recruitment products.
* **Additional Resources:** Product updates, billing and security information, and answers to frequently asked questions—all in one place.
* **AI Assistant:** An AI-powered assistant, trained on our documentation, ready to provide instant troubleshooting help at every stage of your customer journey.
## Picklist Field Configuration
* Users can now easily create and configure picklist fields within the Affinda Platform.
**Options**
* Options are (typically short) lists of values that are added manually through the interface
* The values are sent to the model when the document is processed, and the model predicts the appropriate value from the list
**Data Sources**
* An array of parameters (one or many) that acts as a “lookup” or “master” list
* Typically, this will be master or source data from a customer's system (e.g. ERP, CRM)
* Data Sources can be created by uploading an Excel or CSV file through the Affinda Platform and then maintained through either periodic updates through the same interface, or by syncing the data programmatically
* The raw data extracted from the document is mapped to the Data Source using string matching (either Fuzzy, Partial, or Exact)
See [Picklists ](/configuration/picklists)for more information.
## User Queue Management
* Improved logic to ensure that multiple users are not reviewing the same document simultaneously
* After a user confirms a document, the next document in the queue that is not being looked at by another user will be presented
* In the cases where multiple users have the same document open, the user who opens the document last will have a warning displayed to notify them of another user in the document
## Image & Checkbox Field Types
* Users can now add and configure image and checkbox fields
* **Checkbox Fields:**
* ***Label:*** Use when one or more options may be checked. Returns the label text for each selected option.
* ***True/False:*** Use for a single checkbox. Returns True if checked, False if unchecked.
* ***Image Fields:*** Returns the identified image for **Signatures**, **Headshots** and **Seals of Authenticity**
* The image models are only applied when new documents are uploaded after the fields are created. Previously uploaded documents will need to be re-parsed for the model to extract the relevant image/data.
See [Field Configuration](/configuration/field-configuration) for more information.
## Purchase Credits via Billing Page
* Purchase additional credits directly through the Billing Page in your Affinda Organization - no sales call required.
* Enable Auto-Reload to top up your balance when it gets low automatically
* For high-volume or custom credit packages, our Sales team can configure tailored deals that can still be paid through the platform or via standard invoicing.
See [Billing ](/billing)for more information
## Validation Rule Creation
* Validation rules can now be created through the Affinda Platform by specifying the rule in natural language
* Describe the logic you'd like to apply and reference the relevant fields you'd like to include and Affinda will automatically generate the corresponding rules for you
See [Validation Rules](/configuration/validation-rules) for more information.
## Text Transformations
* Users can now apply transformations to refine extracted text by applying a natural language prompt to be clean, reformat, or transform the data for better usability
* With the description of what transformation to apply, Affinda will process this using either:
* Large Language Models (LLMs) for dynamic text refinement
* Code-based transformations, where possible, ensuring minimal variability in standardized data
* This applies to fields of 'text' data type only
See [Field Configuration](/configuration/field-configuration) for more information.
## Self-Learning Classification
* Affinda has launched new capabilities for document classification - our general model applied on new Workspaces now knows your specific document types and continues to improve as new documents are added to Model Memory
* When a new document is uploaded and needs to be classified, the model uses two key inputs:
1. Document Type Names and Descriptions
2. Reference Documents from Model Memory
See [Document Classification](/configuration/classification) for more information.
## Instant Learning Capability
* Affinda models now benefit by default from instant learning capabilities
* **Learn from Just One Document:** Our system now only needs one example of a particular invoice format to perform accurate data extraction. This eliminates the need to upload multiple examples for model training.
* **Immediate Adaptability:** When you upload a single document of a specific format, our models will immediately apply the learnings to the next document of the same type. This minimizes the setup and preparation time.
* **Higher Accuracy:** With continuous improvements driven by state-of-the-art AI, this latest release excels at recognizing layouts and specific data structures. This ensures high accuracy without extensive training.
See [Information Extraction Models](/configuration/extraction-models) for more information.
## Enhanced Document Splitting Model
* Affinda has launched an improved document splitting model that works well across any document type
* This model has been designed to identify specific cues that indicate a new document, including:
* Change in page numbering sequence (e.g. Page 1)
* Change in key party within the document (e.g. an invoice from a different supplier is identified)
* Change in key document identifier
See [Document Splitting ](/configuration/splitting)for more information.
## Resume Summary launch
* Our new Resume Summary tool for Recruitment Technology automates concise overviews of candidates' experience, skills, and qualifications from their resumes
* The summaries match the resume's language, making the tool suitable for all regions
* Personal details like names, ages, and nationalities are excluded to ensure fair, unbiased recruitment and focus on job fit
See [here](/resumes/resume-summary) for more information.
## 'Raw Values' display
* To provide greater control and visibility to customers, we have introduced a new setting that allows users to view the 'raw' text extracted from the document alongside the 'parsed' value that has been formatted and post-processed
* This means that users can see both values side by side and ensure that the post-processing is accurate.
## New Resume Redactor
* Affinda has launched a new version of our Resume Redactor, delivering higher accuracy and greater configurability
* The model works well across both resumes and cover letters and can be applied across a wider range of fields
See [Resume Redactor](/resumes/resume-redactor) for more information.
## General Redaction capability
* Any document can now be redacted using our new 'redaction' API endpoint
Any fields extracted from a document will be redacted using the endpoint
See [Data Export](/configuration/export-data) for more information.
## Status Page
* Status Page launched to keep customers informed about the performance of our AP and web application across all of our server locations
* To access the Status Page and explore its features, visit [https://status.affinda.com/](https://status.affinda.com/)