TypeScript types from a few API responses

Daily workEN2026-10-28

A saved API response is often the first clear picture of the data your application will receive. You can see the field names, inspect a few values, and start writing code around them. Turning that response into a TypeScript type makes the structure easier to understand and use.

An AI assistant can draft those types from examples. The useful part is the first pass: translating nested objects, spotting repeated structures, and suggesting names. Your part is to check which details describe the API and which belong only to the samples.

§ Start with a small, realistic example

Suppose an API returns this customer record: { "id": "cus_104", "name": "Mina", "email": null, "tags": ["trial"] }. Before sharing a real response with an assistant, replace personal information and remove credentials. Keep the structure and value types intact so the example remains useful.

A reasonable first draft is type Customer = { id: string; name: string; email: string | null; tags: string[]; };. Here, string[] means an array of strings. The vertical bar in string | null means the field accepts either a string or null.

Notice that the example contains only a null email. The possibility of a string comes from our understanding of the field, not from evidence in that single response. A careful assistant should flag that assumption instead of presenting it as certain.

§ Give the assistant more than one record

One example shows one situation. Several examples can reveal fields that disappear, values that change type, and objects that have different shapes. Include ordinary responses alongside meaningful edge cases, such as an empty collection or a record with missing information.

A useful prompt is: Generate TypeScript types from these JSON examples. Use every example. Identify assumptions, distinguish missing fields from null values, and list anything the examples cannot establish. Do not invent fields.

You can send that request through Vana API using an OpenAI SDK with its base URL configured for the service. Vana API provides access to models such as Claude Sonnet 5.5 through one endpoint, with usage billed per real token and no monthly fee. Create an account when you are ready to try the process with a small, sanitized example.

§ Check the places where examples mislead

Generated types deserve a short review before they enter your project. These are the details most likely to need a decision:

Missing and null are different. An optional field, written as email?: string, may be absent. A field written as email: string | null must be present but may contain null. Some APIs allow both.
Empty arrays reveal no item structure. A response containing items: [] does not tell you whether future items are strings, numbers, or objects. Find a populated example or consult the documentation.
Sample values may not define every allowed value. Seeing a status of "pending" does not prove that "pending" is the only valid status. Ask for the documented set before creating a union of specific strings.
JSON dates arrive as strings. A timestamp stays a string in the response type unless your application explicitly converts it into a JavaScript Date.
Numbers can hide meaning. A price of 1200 might represent cents. A TypeScript number does not capture that unit; a clear property name or a comment can help.

§ Keep the type connected to real data

Save the reviewed type near the code that consumes the response, and let TypeScript check how your application uses it. Try representative records, including missing optional fields and empty arrays, to check whether your assumptions hold.

TypeScript checks code during development; its types do not validate incoming JSON at runtime. Writing response as Customer tells the compiler to trust you. It does not inspect the response. When your application needs to reject unexpected data, add runtime validation with a schema library or explicit checks.

As the API changes, keep a few sanitized examples alongside the types. A new field or an unexpected null then becomes something concrete to review, with evidence for the next revision.