## TL;DR

A 400 from the REST record API means the payload is malformed: missing required fields, wrong sublist structure, or bad references. Read the error detail object, which names the failing field; fix the payload shape (lines go in the item or expense sublist with proper segment references), and retry. Log the full error detail, not just the status code.

## Error

```text
400 Bad Request: {"type": "https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1", "title": "Bad Request", "detail": "Invalid value for entity"}
```

## Steps

1. Capture the full error response body, especially the detail field.
   Expected: The named failing field.
2. Verify required header fields: entity, tranDate, subsidiary.
   Expected: Complete headers.
3. Verify sublist structure: item or expense lines with correct references.
   Expected: Well-formed lines.
4. Fix and retry the create.
   Expected: A 201 with the new bill ID.
5. Add payload validation before sending.
   Expected: Fewer 400s.

## When to use

- REST API vendor bill creates fail
- Integration development and debugging
- Migrating from SuiteTalk to REST

## When not to use

- SuiteTalk SOAP errors
- OAuth/token auth failures (401/403)
- CSV imports

## Compatibility

NetSuite REST web services (2021.1+).

## Variant phrasings

### NetSuite REST 400 vendor bill

### bad request creating bill REST API

### REST record API bill error

## Root cause

The REST API validates payload shape strictly and returns terse 400s. Most failures are missing required fields or sublist entries shaped for SOAP rather than REST.

## Edge cases

- Custom fields need the scriptId-based naming in REST
- The error detail can be nested; parse the whole body
- Test in sandbox; 400s are safe (nothing posts)

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_26IcM4RnsBX75h2I3a5v_w