Importing JSON API Responses into a SQL Database

Pulling data out of an API and into a real table is one of the most common reasons to reach for a JSON-to-SQL conversion — you've got a response like this, and you want it in a table you can actually query with joins and indexes instead of parsing JSON in application code every time.

[
  { "id": 101, "name": "Ada Lovelace", "role": "engineer", "active": true },
  { "id": 102, "name": "Grace Hopper", "role": "engineer", "active": true }
]

Flatten nested objects first

A JSON-to-SQL converter works on a flat array of objects — one object per row, each key becoming a column. Real API responses are often nested one or two levels deeper:

[
  { "id": 101, "name": "Ada Lovelace", "address": { "city": "London", "zip": "SW1" } }
]

A nested object like address either needs to be flattened into its own columns (address_city, address_zip) before converting, or pulled out into a separate related table if it repeats across many records — decide which up front rather than after the SQL is generated. Nested arrays (a list of tags per item, for example) are a similar case: they normally belong in their own table with a foreign key back to the parent row, not squeezed into one column.

Inconsistent keys across items

API responses are rarely perfectly uniform — an optional field might be present on some objects and missing on others, or null instead of omitted entirely. Whatever converts the array needs to union the keys across every item to build the full column list, and treat a missing key the same as NULL for that row rather than erroring or silently dropping the column.

Picking a primary key

• If the API response already has a stable unique identifier (an id field, usually), use it as the primary key directly rather than generating a new one — it keeps the table in sync with the source system if you ever need to re-import or reconcile.
• If there's no natural id, an auto-incrementing key is the simpler default, but consider whether you'll need to de-duplicate on re-import (in which case a unique constraint on some combination of fields matters more than the primary key itself).

Type inference from JSON is usually more reliable than from CSV

JSON at least distinguishes numbers, booleans, strings, and null natively, so type inference has less guessing to do than with plain-text CSV. The one thing worth double-checking: numbers that are really identifiers (an order number, a phone number) rather than quantities — those should stay text if leading zeros or exact string matching matter, even though they look numeric.

Don't run untrusted API data straight into production

If the JSON is coming from a third-party or user-facing API rather than an internal source you control, treat the generated INSERT statements as something to review before running — same as you would any data you didn't produce yourself. Malformed or unexpectedly large responses are a more common problem in practice than anything malicious, but reviewing the output before it touches a real database costs a minute and avoids a bad import.

Paste your JSON below

JSON to SQL below handles a flat array of objects, infers column types automatically, and gives you a CREATE TABLE plus INSERT statements ready to review before running.