Endpoint Generator

The Endpoint Generator component allows you to automatically generate an HTTP CRUD web API wrapping your database of choice. The endpoint generator component works by reading meta data from your database, which it then uses to generate Hyperlambda HTTP endpoints for you automatically.

If you use the generator on for instance the “SQLite Sakila” database that you can find as a plugin, Magic will create more than 3,000 lines of Hyperlambda code for you automatically, resulting in some roughly 100 HTTP endpoints for you, providing you with all CRUD operations towards all tables in your database.

Magic can also generate an API wrapping your existing databases. If you want to use your existing databases as input, you’ll have to provide Magic with a connection string that allows it to connect to your database. You can do this through the databases component.

The API Wizard - the guided flow

The fastest way to use the generator is through the “API Wizard” card on the dashboard’s landing page. This starts a guided version of the Endpoint Generator, walking you through three steps - choose data, generate, and done. The guided flow preselects every table in your database, since that is almost always what you want when creating an API from scratch, and if you haven’t got a database of your own yet, it points you to the databases component to create or connect one first.

When generation is done, the guided flow tells you how many endpoints it created and where they live, and links you directly to the endpoints component - filtered to your new module such that you can try your API immediately - and to users and roles, where you control who is allowed to invoke it.

How to use the endpoint generator

To use the endpoint generator component you must first select a database. Then you can optionally configure the CRUD process for individual tables, such as configuring what URL your CRUD API should use, whether or not to turn on caching of HTTP GET endpoints, what authorisation requirements each endpoint should have, etc.

Notice, if you deselect all tables and select only one table, you get a lot more options to choose from. This is useful if you need additional control over how your API endpoints are generated, and what results the endpoint generator should give you.

The Endpoint Generator creates 5 HTTP endpoints by default for each table. One endpoint for each CRUD operation, and a 5th endpoint to count items. If your table does not have a primary key, it will not be able to generate delete or update endpoints. If your primary key has a default value, it will not generate endpoint code requiring a primary key value for its create endpoints. In general, the endpoint generator tries to intelligently choose defaults for your tables as it generates your backend. However, it is not always able to choose correctly for you, so you might want to sanity check its result after you’ve generated your backend.

Additional endpoint types

In addition to the standard CRUD endpoints, the generator can optionally create a few extra query endpoints for a table. You enable these per table before you generate your backend.

• Aggregate - Creates an endpoint that returns the minimum, maximum, average, sum, or count for a column you specify, grouped by another column. The grouping column is mandatory, so the endpoint always returns your aggregate value per group. This lets you produce totals and statistics directly from your database, without writing any SQL yourself.
• Distinct - Creates an endpoint that returns the unique, distinct values from a column, allowing you to list every value that occurs in a column without duplicates.
• Search - Creates an endpoint that performs a “keyword density search” across your table, ranking each row by how many of your keywords it matches, and sorting the result by “most matches” first. This gives you a simple relevance-ranked, full-text style search endpoint out of the box. Keyword density search is actually a good substitute for RAG and VSS - it requires no embeddings, no vector database, and no AI inference, yet often yields surprisingly relevant results, making it a great low-cost alternative when you need search but don’t need semantic understanding.

Below is how the result looks like in Hyper IDE after having generated all endpoint types for a table - one Hyperlambda file per endpoint, including the count, distinct, aggregate, group, and search endpoints.

Endpoint generator settings

Once you have selected a database and a table, you can override individual settings for how Magic should create CRUD endpoints wrapping your specified table. You can also turn on or off specific columns, preventing Magic from accepting values for these columns, also for individual CRUD verbs. If you have a read only type of column for instance, that should only be set during “create” invocations, you can easily remove that field from your “update” endpoint, making sure Magic does not accept new values to that column when its update endpoint is invoked.

You can also override what URLs your endpoints should use, what authorisation requirements your endpoints should have, in addition to a lot of other settings, such as turning on logging, caching, etc.

Endpoint generator settings complete list

Below is a complete list of what settings you can apply when generating your endpoints. Notice, some of these settings are only possible to apply if you’ve selected only one table.

• What fields each CRUD endpoint accepts
• Authorisation requirements for each CRUD endpoint, allowing you to declare which role a user must have to be able to invoke your endpoints
• Primary and secondary URL, allowing you to tell the backend generator what URLs to generate for a particular table
• Paging and sorting, allowing you to turn on or off paging of data and sorting of data
• Additional GET endpoints, such as aggregate, distinct, and search endpoints, giving you more ways to query your table
• Turning on or off logging when your create, update and delete endpoints are invoked
• Caching, implying HTTP cache, or the “Cache-Control” HTTP header, and whether or not to turn on public cache or not, where public caching allows proxies to cache your endpoint’s result. Notice, caching is only applied to GET endpoints in this component
• Overwrite, which if true, will overwrite an existing endpoint. By default, the endpoint generator will not overwrite existing files unless you explicitly tell it to do so

Endpoint generator internals

The endpoint generator will actually create 5 files for you, one file for each CRUD verb, and one file to count items. These files will be Hyperlambda files, and you can see these after the process is done by using Hyper IDE and expand your “modules” folder. The generated Hyperlambda will basically be wrappers around the [data.connect] slot, in addition to one of the following slots, depending upon which CRUD verb the file you’re looking at is wrapping.

• [data.create] - The Hyperlambda slot for creating new items in your database
• [data.read] - The Hyperlambda slot for reading items from your database
• [data.update] - The Hyperlambda slot for updating items in your database
• [data.delete] - The Hyperlambda slot for deleting items from your database

The SQL endpoint generator

The SQL endpoint generator component allows you to generate an API endpoint wrapping an SQL statement. It is similar to the endpoint generator, but instead of automatically creating your SQL, it allows you to provide your own custom SQL, and then securely wrap your SQL into an HTTP endpoint. It allows you to create endpoints wrapping any of the 5 most popular HTTP verbs, takes care of authentication and authorisation, in addition to that it allows you to declare arguments to your endpoints.

Notice, you don’t have to write the SQL yourself. Below the SQL editor you’ll find an input textbox that says “Where the Machine Creates the Code” - describe the query you want in plain English, click “Ask”, and the AI generates the SQL for you, aware of your selected database and its schema. If the editor already contains SQL, your prompt is treated as a change instruction, allowing you to iterate until the query does exactly what you want, before wrapping it into an HTTP endpoint.

How to use the SQL endpoint generator

You can find the SQL endpoint generator as an additional tab inside your endpoint generator. The SQL generator is much simpler to understand than the endpoint generator, since it has much less settings you can apply. However, the SQL endpoint generator obviously requires that you’ve got a solid understanding of SQL. The process to use the SQL endpoint generator to create an endpoint is as follows.

1. Choose your database
2. Choose an HTTP verb
3. Choose URL(s) for your endpoint
4. Select which roles are authorised to invoke your endpoint (optional)
5. Provide arguments to your endpoint (optional)
6. Write your SQL referencing arguments if you provided arguments in the above step

When you’re done with the above, simply click the “Generate” button, and you’ve got an HTTP endpoint wrapping your SQL.

Settings for the SQL generator

The SQL generator allows you to override authorisation requirements, the URL of your endpoint, and which arguments your endpoint requires. The last part is important since it allows you to add arguments to your endpoint that you can reference in your SQL somehow. To reference an argument in your SQL, prefix your argument’s name with an at character (@), implying if your argument is named “foo”, you’ll have to reference your argument in your SQL as “@foo”.

Notice, arguments supplied to your SQL endpoint are obviously mandatory, since once you’ve generated your endpoint, there are no known mechanisms for removing the argument from your SQL. However, your arguments could be supplied as null values, at which point the resulting SQL would use the value null as a substitute for your argument.

The Sandbox API generator

The “Sandbox API” tab generates a single endpoint that safely executes code its own callers supply. Where the CRUD and SQL generators turn your data and your SQL into fixed endpoints, the Sandbox API publishes one endpoint that accepts Hyperlambda - or a plain-English instruction it turns into Hyperlambda - from whoever calls it, and runs it inside a whitelist that decides, function by function, what that code is allowed to do. The caller never gets more power than the roles you granted, and a function you did not grant simply does not exist as far as their code is concerned.

This is the same mechanism behind the public Natural Language API demonstration, generalised so you can shape the vocabulary, the rate limit and the timeout per role, and mount it at a URL of your choice.

Input - Hyperlambda, natural language, or both

The “Input” selector decides what the generated endpoint accepts, and your choice is reflected both in the endpoint’s arguments and in its documentation.

• Hyperlambda - the endpoint takes a [hyperlambda] argument and executes it as-is
• Natural language - the endpoint takes an [instruction] argument, sends it to the Hyperlambda Generator for code, and executes the result
• Both - the endpoint accepts either; a non-empty [instruction] is used when present, otherwise the [hyperlambda] argument

Whichever you choose, the generator writes a matching file level comment and argument comments, so the endpoint documents itself - and, because it becomes an MCP tool, so does the tool an AI agent sees.

How the code is checked and run

Every request goes through the same pipeline.

1. Verify - the code is parsed and every function it references is checked against the functions that actually exist on this server. A hallucinated function stops here, before anything runs.
2. Execute - the code runs inside a [whitelist] whose vocabulary is chosen from the caller’s roles. A function that is not in the vocabulary does not resolve, and an argument that is pinned - such as a database name - must match exactly.
3. Return - the response always carries a [state] saying what happened, the [result] the code produced, and a [reason] when the runtime refused the code or it failed.

The possible states are executed, rejected (a function or a pinned argument was not allowed), unknown-slot (a referenced function does not exist), error (the code threw), timeout (execution exceeded the configured limit), and generator-failed (no code came back from the generator).

The policy - base vocabulary plus per-role grants

What the sandbox can reach is defined by a policy you build in the component, made of an “everybody” base rule plus any number of per-role rules.

• Everybody (base vocabulary) - the language every caller gets, seeded for you with a safe set of pure, data-shaping functions (mirroring the public Natural Language API’s vocabulary, minus database and HTTP access). It also carries the fallback rate limit and timeout.
• Role rules - each adds more functions on top of the base for callers in that role. This is how you grant your CEO’s role access to one database while your HR role cannot reach it - both keep the base language, and each role’s extra functions are added to it.

The vocabulary a given caller runs with is the union of every rule they match, so capabilities compose. The rate limit and the timeout are resolved independently - each is taken from the first matching rule, top to bottom, that declares it, so you order your rules most-privileged first and never have to calculate a maximum. The base rule sits last as the fallback for both.

Functions are written one per line. A bare name such as data.read grants the function; a name with a value such as data.connect:northwind pins its primary argument - here restricting database access to exactly the northwind database. File and folder functions pin their path the same way, so io.file.load:/etc/reports/ grants loading exactly that path.

Capability wizards

Typing function names by hand is error-prone, so each role rule carries a row of wizards that write the correct lines for you. The “Add capability” buttons cover Database, HTTP, Files, Email, Images, Logging, Tasks, Cache, Sockets, Identity, Crypto, AI, and a headless Browser. The Database wizard lets you pick a database and tick Read, Create, Update and Delete, and writes the pinned [data.connect] line plus a function per operation. The Files wizard grants Read, Write and/or Delete and can pin them all to a path. Deliberately omitted are configuration - which would expose secrets - and ticket minting, which is the one escalation the sandbox exists to prevent, so the Identity wizard is read-only.

Root, throttling and the timeout

Two settings sit above the policy.

• Root bypasses the sandbox - when on, a caller in the root role runs with the server’s full vocabulary and no whitelist at all. Root is trusted completely, so it is also never rate limited and never timed out, whether or not this is on - the setting only controls whether root additionally escapes the vocabulary restriction.
• Return code - when on, the response includes the generated or supplied code; when off, only the state, result and any reason come back, which is usually what an application calling the endpoint wants.

Rate limiting is per role, keyed by the caller’s IP address, and the timeout cancels execution after the configured number of milliseconds - a caller’s own code can shorten it, but never extend it.

Who may call, and self-description

The “Who may call” row gates the endpoint itself, exactly as for the other generators - leave it empty for a public endpoint, or name the roles allowed to invoke it. A caller who gets past that gate is then further constrained by the policy.

Because the generated endpoint is an ordinary Hyperlambda endpoint, it is also an MCP tool. Its file level comment - which the generator writes to match the input mode - becomes the tool’s description, and it even tells the calling model how to discover its own capability surface: sending the instruction “Return server vocabulary”, or Hyperlambda invoking [vocabulary], lists exactly the functions that particular sandbox permits.

Import API - wrapping a third party API

The fourth tab in the Endpoint Generator, “Import API”, works the other way around from the other three. Instead of generating endpoints from your own database or your own SQL, it reads an OpenAPI specification belonging to somebody else’s API - Stripe, GitHub, Slack, or any other API that publishes one - and generates Hyperlambda endpoints in your cloudlet wrapping the operations you choose.

Paste the URL of the specification and click “Read”. Magic fetches and parses it, then shows you every operation it found, grouped by the specification’s own tags - or by the first meaningful segment of the path for specifications that don’t use tags. Tick the operations you want, give the module a name, and click “Import”. A terminal dialog reports each endpoint as it is created, and tells you how many lines of Hyperlambda it generated when it finishes.

Both major dialects are supported - OpenAPI 3.x and the older Swagger 2.0 - in either JSON or YAML. Specifications range from a handful of operations to well over a thousand, so the filter box and the group checkboxes let you pick out just the parts of an API you actually intend to use.

Arguments and documentation

The generated endpoints are ordinary Hyperlambda endpoints, and they are documented from the specification as they are generated. URL parameters, query parameters, and form fields each become a named, typed argument with its own comment stating the type, whether it is required, its default value, the values it accepts, and the description the specification gave it. Required arguments get a [validators.mandatory] invocation, so a missing argument is refused before the upstream API is ever contacted.

This matters beyond readability. Magic exposes the file level comment as an endpoint’s description and each argument’s comment as that argument’s description, which is exactly what an MCP client reads when deciding how to call a tool. An imported API therefore arrives as a set of self describing tools an AI agent can use without any further work from you.

Authentication towards the upstream API

Most third party APIs require a credential. You choose how the generated endpoints should authenticate - a bearer token, a custom header, a query parameter, or nothing at all - and which configuration key the credential is read from. The credential itself is never written into the generated files. It is read from your configuration at the moment the endpoint is invoked, so your files stay safe to check into source control. The “Set” button next to the configuration key lets you store the credential without leaving the component.

You also declare which of your own roles are allowed to invoke the generated endpoints, exactly as you do for CRUD endpoints, so wrapping a third party API does not implicitly expose it to everybody.

Request bodies

Magic generates different code depending upon what the operation expects, which it reads from the specification.

• JSON - The endpoint takes a [payload] argument, and the fields the specification declares are documented above it, nested objects included.
• Form encoded - Each field becomes a named argument of its own, unless the specification nests objects deeply enough to require bracketed keys, in which case the endpoint keeps a single [payload] argument.
• Multipart - The endpoint accepts a file upload, and forwards it to the upstream API under the field name the specification asks for.
• Binary - The endpoint accepts the raw request body and passes it on untouched, which is what APIs accepting an image or a document directly expect.

By default the importer refuses to replace an endpoint that already exists, telling you which file was in the way. Tick “Overwrite existing files” to re-import over an existing module, which is what you want when the upstream specification has changed and you need to regenerate.

HTTP verbs

The CRUD endpoint generator creates endpoints wrapping the POST, GET, PUT, and DELETE verbs, while the SQL and Sandbox API generators can additionally wrap PATCH.

• POST - Typically used for creating or inserting new items
• GET - Typically used for retrieving or counting records
• PUT - Typically used for updating values in your database
• PATCH - Alternative to PUT with similar semantics, typically when adding new fields (SQL and Sandbox API generators)
• DELETE - Typically used when deleting records in your database.

Frequently asked questions

What does the Endpoint Generator do?

It reads metadata from your database and automatically generates a complete CRUD web API wrapping it, secured according to your instructions. What would normally take weeks of coding is done in seconds.

Which databases can it wrap?

Any MySQL, PostgreSQL, SQL Server, MariaDB, or SQLite database - including existing legacy databases, which makes it a fast way to put a modern, secure API on top of an old system.

Which endpoint types can it generate?

POST, GET, PUT and DELETE endpoints for each table, plus additional GET endpoints such as count, aggregate, distinct, and a keyword density search endpoint.

What is keyword density search?

A search endpoint that ranks each row by how many of your keywords it matches, sorting by most matches first. It is a good substitute for RAG and VSS - no embeddings, no vector database, no AI inference - yet often yields surprisingly relevant results.

Is the generated API secure?

Yes. You declare which roles can invoke each verb, and the generator takes care of authentication, authorisation, validators, and referential integrity - plus optional logging of create, update and delete invocations.

Does caching apply to all generated endpoints?

No. Caching, implying the Cache-Control HTTP header, is only applied to GET endpoints in this component.

What is the fastest way to create an API?

The dashboard's landing page has an 'API Wizard' card starting a guided version of the Endpoint Generator - it preselects every table in your database, and when generation is done it links you directly to your new endpoints and to user management.

Can I wrap somebody else's API instead of a database?

Yes. The Import API tab reads an OpenAPI specification - OpenAPI 3.x or Swagger 2.0, JSON or YAML - and generates Hyperlambda endpoints wrapping whichever operations you select, complete with arguments, validators and documentation taken from the specification.

Where is the credential for an imported API stored?

In your configuration, never in the generated files. You nominate a configuration key, and the generated endpoints read the credential from it at invocation time, which keeps your files safe to check into source control.

Do imported endpoints work as MCP tools?

Yes. The importer writes the operation's summary as the file level comment and each argument's documentation as a comment above that argument, which is what Magic exposes as the tool's description and its arguments' descriptions - so an imported API becomes a set of self describing tools for an AI agent.

Can I wrap my own SQL in an endpoint?

Yes. The SQL endpoint tab lets you provide any SQL statement, declare arguments you reference as @name in the SQL, choose an HTTP verb and authorisation, and generate a secure endpoint wrapping it. The AI prompt bar can even write the SQL for you, and you can load saved snippets or import .sql files.

What is the Sandbox API tab?

It generates one endpoint that safely executes code its own callers supply - Hyperlambda, or plain English turned into Hyperlambda - inside a whitelist you define per role. Callers can only reach the functions you granted, a function you did not grant does not exist as far as their code is concerned, and a hallucinated function is refused before anything runs.

How do I limit what a Sandbox API caller can do?

You build a policy from an 'everybody' base vocabulary plus per-role rules that add functions on top. A caller runs with the union of the functions their roles grant, so you can, for example, give one role access to a specific database while another role cannot reach it. The rate limit and the execution timeout are set per role too, and root is trusted completely - never sandboxed, throttled, or timed out.

Can the Sandbox API run a natural-language instruction?

Yes. Choose the natural-language or 'both' input mode, and the endpoint sends the instruction to the Hyperlambda Generator, verifies every function the generated code references actually exists, and runs it inside the same whitelist. The response says whether it executed, and why not when it was refused.

Does the Sandbox API endpoint work as an MCP tool?

Yes. The generator writes the endpoint's file level comment to match its input mode, which Magic exposes as the tool's description, and the comment even tells the calling model how to discover its own capability surface - by asking the tool to 'Return server vocabulary'. An AI agent can therefore learn exactly which functions a given sandbox permits before it calls it.