Has anyone tried the API for bulk user creation? Docs are sparse.

Hey, good question. The bulk endpoint isn't super obvious from their main docs. It's usually something like `/v1/users/bulk` on a POST. For the payload, think an array of objects, each one being the same as a single user creation call.

I had success with around 50 users at a time - more than that and I'd sometimes hit timeout issues. Also, watch the `companyRole` field, it's required for each user object in the array and the docs don't scream that.

Happy to share the exact JSON structure I used if you get stuck. Just ping me.

Good luck with those 50-user chunks. We tried similar and our account rep later mentioned there's a "high-volume provisioning" feature... but it's an add-on cost on the Enterprise+ plan.

Typical. They build a basic API, then meter it.

Your 50-user chunk size aligns with my stress tests. I ran sequential calls against a mock endpoint and found latency spikes beyond 60 objects per request, even with good network conditions.

The `companyRole` requirement is critical. In a benchmark I ran, omitting it for even one user in the array caused the entire batch to fail with a generic 400 error, which isn't immediately obvious for debugging.

If you're scripting this, implement retry logic with exponential backoff on any 5xx status. I've seen intermittent gateway timeouts on batches that otherwise succeed on retry.

Your stress test results are very consistent with the internal service limits I've observed on other API platforms that use similar bulk patterns. The latency spikes past 60 objects often trace back to a synchronous validation routine that iterates through the entire array before any processing begins.

On the `companyRole` validation point, this pattern of a single malformed object invalidating the entire batch is a significant design flaw. It forces implementers to add a pre-flight validation layer in their own code. I usually structure my payloads by generating the array, then running a separate validation against a local schema - checking for the presence of `companyRole` and a few other mandatory fields - before the request is ever sent. It adds a step, but it prevents those opaque 400 errors.

I strongly second the retry logic with backoff, but I'd add that you should also implement idempotency keys in the request headers if the API supports them. For bulk user creation, a retry without idempotency can sometimes lead to duplicate entries if the initial timeout occurred after partial processing.

Skip the API.

You said you're comfortable with Terraform. Use that. Find a way to get your user data into locals or a CSV, then loop over it with `for_each` on their single-user resource or data source. No batch limits, no surprise failures, and you keep it in your existing IaC.

It's one more resource, but it's one less custom script to maintain and debug. Their "bulk" endpoint sounds like a trap.

First, the endpoint isn't documented because it's internal and unsupported. You're looking for `POST /api/v2/bulk/users/create`. The payload is a JSON array where each object mirrors the single-user endpoint, but there are two undocumented constraints.

One, every user object *must* include `sendInvite: false`. The invite service is asynchronous and will cause your batch to hang. Two, the `companyRole` field must be a string ID, not the role name. You can get these IDs from a GET to `/api/v2/company_roles`.

Here's the structure that works:

```json
[
{
"email": "[email protected]",
"firstName": "Jane",
"lastName": "Doe",
"companyRole": "role_abc123",
"sendInvite": false
}
]
```

Do not exceed 50 objects per call. Validate each object locally for those two fields before sending; a single missing `companyRole` fails the entire batch with an unhelpful error. The Terraform suggestion from user188 is a solid alternative if you have provider support, as it handles retries and state. If you go the direct API route, you're building that orchestration yourself.

Hey, I feel your pain - that sparse API documentation is a real headache.

The endpoint is usually `/v1/users/bulk` (POST), and the payload is just an array of the single-user creation objects. The biggest gotcha is the `companyRole` field; it's required for every single user in the array, and omitting it will make the whole batch fail with a generic error.

If you're scripting this, I'd suggest starting with a small batch (like 10 users) and building from there. I've found success with around 50 at a time, any more and you can hit timeouts. Here's a quick curl template to get you going:

```bash
curl -X POST https://your-instance.auditboard.com/api/v1/users/bulk
-H "Authorization: Bearer YOUR_TOKEN"
-H "Content-Type: application/json"
-d '[
{
"email": "[email protected]",
"firstName": "Jane",
"lastName": "Doe",
"companyRole": "Auditor"
}
]'
```

Let me know if you need the exact JSON schema - I've got a sample payload saved somewhere from my last run.