Asynchronous Execution
Batch operations are asynchronous. Every batch endpoint returns anasync_task handle that you use to track completion and retrieve the affected entities.
The task may or may not have completed by the time you receive the response — data.status could be processing or completed. Partners must always check data.status and not assume the work has finished.
You have two ways to observe completion:
- Poll the URL in
links.selfon the response untildata.statusiscompleted(orerror). - Subscribe to the
async_task_completedwebhook event, which fires when the task finishes.
Batch Upsert
Nmbr’s API allows you to create or update (“upsert”) multiple entities of a single type in a single API call.Endpoint
POST /<type>s/batch/upsert
<type> can be one of the following types:
- Recurrences
pay_rateallowancedeductionearningemployee_benefitemployer_benefitreimbursement
- Line Items
allowance_line_itemdeduction_line_itemearning_line_itememployee_benefit_line_itememployer_benefit_line_itemreimbursement_line_item
- Other
employeecontractorwork_assignment
Request
The body of the request must be an array of entity objects. These properties of the entity objects are documented in the API reference for each entity type, but in general the batch upsert endpoint takes the same properties with the same restrictions as the one-off create or update endpoints. If an object includes anid property, the existing entity with that ID will be updated. Otherwise, a new entity will be created.
For example, this request updates one existing earning line item (with ID ernli_01J8KXC9R4MQVW2FXZN7Y5H3B8) and creates two new earning line items:
POST /earning_line_items/batch/upsert
Response
On success, the operation returns202 Accepted with an async_task handle. See Asynchronous Execution for how to track completion. ⚠️ Partners must treat any 200-level response as success. ⚠️
For example, the response to the upsert request above might look like:
links.self and see data.status change, or when the async_task_completed webhook arrives — data.results will contain one entry per request entity, in the same order. results[n] corresponds to data[n] in the request body, whether the entity was created or updated:
422 Unprocessable Entity with standard validation messages.
In order to identify which entity in the request the validation messages apply to, the validation message keys will be prefixed with data.n., where n is the zero-based index of the entity. For example, if the first earning entity in a request had an invalid business_preset_id value, the validation message key would be data.0.business_preset_id
Notes
- If any entity fails validation, no entities will be created or updated.
- When using a
business_preset_id, properties must either be omitted or match the preset’s values. - If batch upserting line items, the payroll’s totals are automatically recalculated after the batch upsert.
- If batch upserting line items, the payroll must be in draft status.
Batch Delete Line Items
Nmbr’s API allows you to delete multiple entities of a single type in a single API call.Endpoint
POST /<type>s/batch/delete
<type> can be one of the following types:
- Recurrences
pay_rateallowancedeductionearningemployee_benefitemployer_benefitreimbursement
- Line Items
allowance_line_itemdeduction_line_itemearning_line_itememployee_benefit_line_itememployer_benefit_line_itemreimbursement_line_item
- Other
employeecontractorwork_assignment
Request
The body of the request must be an array of the IDs of the entities to delete. For example, this request deletes three earning line items:POST /earning_line_items/batch/delete
Response
On success, the operation returns202 Accepted with an async_task handle. See Asynchronous Execution for how to track completion. ⚠️ Partners must treat any 200-level response as success. ⚠️
For example, the response to the delete request above might look like:
links.self and see data.status change, or when the async_task_completed webhook arrives — data.results will contain one entry per request ID, in the same order. results[n] corresponds to data[n] in the request body. Deleted entities are still surfaced by ID — the records soft-delete and remain queryable:
422 Unprocessable Entity with standard validation messages.
In order to identify which entity in the request the validation messages apply to, the validation message keys will be prefixed with data.n., where n is the zero-based index of the entity. For example, if the first entity in a request couldn’t be deleted because it was a managed line item, the validation message key would be data.0.is_managed
Notes
- If any entity fails validation, no entities will be deleted.
- If batch deleting line items, the line item must not be a managed line item.
- If batch deleting line items, the payroll’s totals are automatically recalculated after the batch delete.
- If batch deleting line items, the payroll must be in draft status.

