# Create API Key Source: https://docs.avicenna.dev/api-reference/api-keys/create POST /admin/api-keys Add a new API key to authenticate endpoint requests. ## Body Parameters The API key reference name. Maximum 50 characters. The ratelimit assigned to this specific API key. Measured in requests per minute. The API key can be assigned either the `user` or the `admin` permission. * `user`: Allows access only to unprotected endpoints or endpoints with the `user` type authentication enabled. * `admin`: Allows access to all endpoints by default and admin endpoints (manage API keys). ```bash cURL theme={null} curl -X POST https://YOUR_API_SUBDOMAIN.avicenna.run/admin/api-keys \ -H 'Authorization: Bearer avcna_sk_xxxxxxxxx' \ -H 'Content-Type: application/json' \ -d '{ "name": "Admin Key Production", "ratelimit_min":120, "permission":"admin" }' ``` ```json Response theme={null} { "success": true, "key": "avcna_sk_2675c53f9ed29fdac811b4c3bdda5b32598832523e4836fbdeadc1510b877812", "key_data": { "id": "6c3c3816-b8ad-4279-8fe0-1d19a0640f96", "name": "Admin Key Production", "last_used_at": null, "created_at": "2026-01-01T00:00:00+00:00", "ratelimit_min": 120, "permission": "admin" } } ``` # Delete API Key Source: https://docs.avicenna.dev/api-reference/api-keys/delete DELETE /admin/api-keys/:api_key_id Delete an existing API key. ## Path Parameters The API key ID (not the API key itself). ```bash cURL theme={null} curl -X DELETE https://YOUR_API_SUBDOMAIN.avicenna.run/admin/api-keys/6c3c3816-b8ad-4279-8fe0-1d19a0640f96 \ -H 'Authorization: Bearer avcna_sk_xxxxxxxxx' ``` ```json Response theme={null} { "success": true, "message": "API key deleted" } ``` # Introduction Source: https://docs.avicenna.dev/api-reference/introduction Example section for showcasing API endpoints If you're not looking to build API reference documentation, you can delete this section by removing the api-reference folder. ## Welcome There are two ways to build API documentation: [OpenAPI](https://mintlify.com/docs/api-playground/openapi/setup) and [MDX components](https://mintlify.com/docs/api-playground/mdx/configuration). For the starter kit, we are using the following OpenAPI specification. View the OpenAPI specification file ## Authentication All API endpoints are authenticated using Bearer tokens and picked up from the specification file. ```json theme={null} "security": [ { "bearerAuth": [] } ] ``` # Changelog Source: https://docs.avicenna.dev/changelog ## SSS ssss # Authentication Source: https://docs.avicenna.dev/guides/dashboard/authentication Create and manage API keys used to authenticate requests to your endpoints. The **Authentication** page allows you to generate and manage **API keys** used to securely access your endpoints. Every request sent to an Avicenna endpoint can be protected using an API key to ensure that only authorized clients can access your API. Authentication Page *** ## Overview API keys act as credentials for your API. When authentication is enabled for an endpoint, requests must include a valid API key or they will be rejected. Each API key includes: * **Name** – A reference name for identifying the key * **Ratelimit** – Maximum allowed requests per minute * **Last Used** – The last time the key was used in a request * **Created** – When the key was generated *** ## Creating an API Key To create a new API key: 1. Open the **Authentication** page 2. Click **Create API Key** 3. Enter a **Name** for the key 4. Set a **Rate limit** 5. Click **Add** add key The key will immediately become active and can be used to authenticate requests. *** ## API Key Name The **Name** field is used purely for identification. Examples: ``` Production Server Frontend App Testing Environment Internal Tools ``` Using clear names helps keep keys organized when managing multiple clients or environments. *** ## Rate Limiting Each key can have its own **rate limit**, measured in **requests per minute**. Example: ``` 60 req/min ``` Rate limits help protect your API from: * Abuse * Traffic spikes * Misconfigured clients * Infinite request loops If a client exceeds the allowed rate, the request will be rejected. *** ## Using an API Key To authenticate a request, include your API key in the request headers. Example: ``` Authorization: Bearer YOUR_API_KEY ``` Example request: ```bash theme={null} curl https://your-endpoint.avicenna.run/test \ -H "Authorization: Bearer YOUR_API_KEY" ``` If the key is valid and within its rate limit, the request will be processed normally. *** ## Last Used The **Last Used** field shows when the key was most recently used. This helps you: * Identify inactive keys * Detect unexpected usage * Monitor API access patterns *** ## Deleting API Keys You can delete an API key at any time using the **delete icon** next to the key. Once deleted: * The key **immediately stops working** * Any clients using it will receive authentication errors If a key is compromised, delete it immediately and generate a new one. *** ## Security Practices To keep your API secure: * Never expose API keys in public repositories * Do not embed keys directly in frontend applications * Rotate keys periodically * Use separate keys for different services If you believe a key has been leaked, delete it immediately. *** ## When to Use Authentication Authentication should be enabled when: * Your API is used by **private services** * You need to **limit access** * You want to **rate-limit clients** * Your API handles **sensitive operations** Public endpoints may not require authentication, but most production APIs should enable it. # Logs Source: https://docs.avicenna.dev/guides/dashboard/logs View and monitor all requests made to your API endpoints. The **Logs** page provides a complete history of requests made to your API endpoints. It allows you to monitor traffic, debug issues, and analyze performance in real time. logs *** ## Overview Each log entry represents a single request made to one of your endpoints. For every request, you can see: * Endpoint path * Timestamp * HTTP method * Response status * Execution duration This makes it easy to identify errors, slow endpoints, or unusual traffic patterns. *** ## Filters At the top of the page, you can filter logs by: ### Endpoint Filter by a specific endpoint path to isolate activity. Example: ``` /test1 ``` *** ### Status Filter by HTTP response status code. Common status codes: * `200` → Successful request * `400` → Bad request * `401` → Unauthorized * `404` → Not found * `500` → Internal server error Filtering by status is especially useful when debugging failures. *** ### Method Filter by HTTP method: * `GET` * `POST` * `PUT` * `PATCH` * `DELETE` This helps narrow down activity when an endpoint supports multiple request types. *** ## Log Fields Each row in the logs table contains the following columns: | Field | Description | | -------- | ----------------------------------- | | Endpoint | The path that was requested | | Time | When the request was made | | Method | The HTTP method used | | Status | The HTTP response status code | | Duration | Total execution time of the request | *** ## Duration The **Duration** value shows how long the request took to complete. * Measured in milliseconds (ms) * Includes the full execution of your flow * Helpful for performance monitoring If durations are unexpectedly high, review: * External API calls * AI generation blocks * Email sending * Complex flow logic *** ## Pagination If your API receives a high volume of traffic, logs are divided into pages. Use **Back** and **Next** to navigate between pages. *** ## Debugging Workflow When troubleshooting an issue: 1. Filter by the relevant endpoint 2. Filter by failing status codes (e.g., `400` or `500`) 3. Review duration for performance anomalies 4. Reproduce the request if needed The **Logs** page is your primary tool for diagnosing issues and monitoring the health of your API. # Settings Source: https://docs.avicenna.dev/guides/dashboard/settings Configure your API’s general settings, authentication, and integrations. The **Settings** page allows you to configure your API’s core configuration, security requirements, and external integrations. These settings apply to the entire API project. settings *** ## General The **General** section defines your API’s identity and access behavior. ### Project Name The **Project Name** is your API’s internal reference name. * Used for identification inside your dashboard * Does not affect the public endpoint URL * Can be changed at any time This is useful when managing multiple APIs. *** ### Subdomain The **Subdomain** determines where your API is hosted. For example: ``` https://your-subdomain.avicenna.run ``` Once saved, your API will be accessible through this subdomain. Changing the subdomain may affect any applications currently using your endpoint. *** ### Require Authentication When **Require Authentication** is enabled: * All incoming requests must include a valid API key * Requests without a valid key will be rejected API keys are managed in the **Authentication** section of your dashboard. This setting is recommended for production APIs. *** ## Integrations The **Integrations** section allows you to connect third-party services that can be used inside your endpoint flows. Once connected, these integrations become available in relevant blocks (e.g., Generate Text, Send Email). *** ### ChatGPT The **ChatGPT** integration enables: * AI text generation * AI image generation * Prompt-based automation inside flows Required for using the **Generate Text** block. *** ### Resend The **Resend** integration enables: * Sending transactional emails * Sending broadcast emails * Dynamic email content using variables Required for using the **Send Email** block. *** ## Saving Changes After modifying any settings: 1. Click **Save** 2. Changes are applied to your API project Some changes (such as subdomain updates) may require a short propagation period before taking effect. *** The **Settings** page centralizes your API’s identity, security configuration, and connected services, ensuring your endpoints run securely and integrate seamlessly with external tools. # Decode Text Source: https://docs.avicenna.dev/guides/workshop/actions/decode-text Decode text using standard encoding formats The **Decode Text** action allows you to decode text from various different formats into standard readable text. Decoding is required when a service (such as an external API) provides an encoded form of text that you need to decode and use in your endpoint. Screenshot2026 01 28at7 13 19PM *** ### Input Text The **input text** is the base text value that will be decoded. This may be static text or a variable. ### Encoding Method The **encoding method** is the format of encoding that your text value is in. Below are listed the available formats that a text value can be decoded from using the Decode Text action: | **Format** | **Description** | **Example Output** | | ---------- | ----------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------- | | Base64 | Helps prevent data corruption in JSON, HTTP Headers, etc. | `SGVsbG8gVGhlcmU=` | | Base64URL | URL-safe version of Base64 that prevents corruption in URLs, query parameters, etc. | `SGVsbG8gVGhlcmU` | | Hex | Converts to hexadecimal with a base-16 format for compacting and safety | `48656c6c6f205468657265` | | UTF-8 | Efficient endocing format used for web services and multilingual compatibility | `Hello There` | | ASCII | Standard binary integer used to represent English characters | `Hello There` | | Binary | Foundational 2-bit encoding format used at the deepest levels of computing | `01001000 01100101 01101100 01101100 01101111 00100000 01010100 01101000 01100101 01110010 01100101` | ### Reference Variable Screenshot2026 01 28at7 30 26PM This variable allows you to refer to the result of the text decoding in future action blocks down your endpoint's flow. This variable must be assigned a custom name. Make your reference variable names as descriptive and unique as possible to prevent your endpoint flow from becoming cluttered. If a future variable is assigned the same name, the value of your reference variable will be overriden. # Encode Text Source: https://docs.avicenna.dev/guides/workshop/actions/encode-text Encode text using standard encoding formats The **Encode Text** action allows you to encode text into various different formats. Encoding is useful when a service (such as an external API) is only compatible with certain encoding formats. Screenshot of the Encode Text action block *** ### Input Text The **input text** is the base text value that will be encoded. This may be static text or a variable. ### Encoding Method The **encoding method** is the format of encoding that will be used on your text value. Below are listed the available formats that can be used to encode a text value using the Encode Text action: | **Format** | **Description** | **Example Output** | | ---------- | ----------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------- | | Base64 | Helps prevent data corruption in JSON, HTTP Headers, etc. | `SGVsbG8gVGhlcmU=` | | Base64URL | URL-safe version of Base64 that prevents corruption in URLs, query parameters, etc. | `SGVsbG8gVGhlcmU` | | Hex | Converts to hexadecimal with a base-16 format for compacting and safety | `48656c6c6f205468657265` | | UTF-8 | Efficient endocing format used for web services and multilingual compatibility | `Hello There` | | ASCII | Standard binary integer used to represent English characters | `Hello There` | | Binary | Foundational 2-bit encoding format used at the deepest levels of computing | `01001000 01100101 01101100 01101100 01101111 00100000 01010100 01101000 01100101 01110010 01100101` | ### Reference Variable Screenshot of reference variable settings This variable allows you to refer to the result of the text encoding in future action blocks down your endpoint's flow. This variable must be assigned a custom name. Make your reference variable names as descriptive and unique as possible to prevent your endpoint flow from becoming cluttered. If a future variable is assigned the same name, the value of your reference variable will be overriden. # Generate Text Source: https://docs.avicenna.dev/guides/workshop/actions/generate-text Use AI to generate text from a prompt within your flow. The **Generate Text** action allows you to generate text dynamically during your endpoint execution using your connected ChatGPT integration. At runtime, this block sends your prompt to the selected model and stores the generated output for use in later blocks. This action requires the **ChatGPT Integration** to be configured in order to run. Your endpoint flow will ignore this block if the integration is not properly configured. Screenshot2026 02 26at6 48 48PM *** ### Prompt The **prompt** field is the instruction sent to the model. You write constant instructions that will always be the same, or use variables within your instructions to customize the generated text every time the endpoint is run! For example: ```text theme={null} Write a short welcome email for {params.partner}. ``` ### Model The **model** dropdown defines which model generates the response. Different models can vary in speed, cost, output quality, or context length. Choose the model that best fits your use case. ### Temperature The **temperature** value controls how deterministic or creative the output is. * `0.0` → Very deterministic and predictable * `0.5` → Balanced * `1.0` → More creative and varied Lower values are ideal for structured or factual outputs. Higher values are better for brainstorming or creative writing. ### Reference Variable Screenshot2026 02 26at7 01 06PM This variable allows you to refer to the result of the text generation in future action blocks down your endpoint's flow. This variable must be assigned a custom name. Make your reference variable names as descriptive and unique as possible to prevent your endpoint flow from becoming cluttered. If a future variable is assigned the same name, the value of your reference variable will be overriden. # Manipulate Image Source: https://docs.avicenna.dev/guides/workshop/actions/manipulate-image Adjust an image using filters and color operations The **Manipulate Image** action allows you to apply visual filters to an image URL inside your endpoint flow. You can use this to adjust image appearance such as contrast, brightness, blur, hue, and more. ManipulateImageBlockSS *** ### Image Preview The block includes a live **image preview** so you can quickly verify how your selected operation and values will affect the image before continuing your flow. ### Image URL The **Image URL** field is the source image that will be manipulated. This can be a direct URL or a variable. ### Operation The **operation** determines which filter is applied to the image. Below are the available options: | **Operation** | **Description** | **Example Value** | | ------------- | ------------------------------------------------------------------------------- | :---------------- | | Contrast | Increases or decreases the difference between dark and light parts of the image | `120%` | | Brightness | Makes the image lighter or darker overall | `90%` | | Saturation | Increases or decreases color intensity | `140%` | | Grayscale | Converts the image toward grayscale | `80%` | | Invert | Inverts the image colors | `100%` | | Blur | Applies a blur effect | `5px` | | Hue Rotate | Rotates all colors around the hue wheel | `45deg` | ### Reference Variable ManipulateImageResultSS The **Reference Variable** allows you to store the manipulation result in a variable. After setting a reference variable, you can use `{result.my-image-name}` in future actions to refer to the manipulated image URL. Make your reference variable names as descriptive and unique as possible to prevent your endpoint flow from becoming cluttered. If a future variable is assigned the same name, the value of your reference variable will be overriden. # Manipulate Text Source: https://docs.avicenna.dev/guides/workshop/actions/manipulate-text Modify a text value using various operations The **Manipulate Text** action allows you to modify text values by applying various different manipulation operations on the text. Screenshot2026 01 27at9 23 10PM *** ### Input Text The **input text** is the base text value that the manipulative operation will be performed upon. This may be static text or a variable. ### Operation The **operation** dictates the way your text vaue will be manipulated. Below are listed the available operations that can be applied to a text value using the Manipulate Text action: | **Operation** | **Description** | **Example Output** | | ------------------ | ------------------------------------------------------------------------------------------ | :----------------- | | To Uppercase | Converts text to all capital letters | HELLO THERE | | To Lowercase | Converts text to all lowercase letters | hello there | | Trim Spaces | Removed all spaces from the text, including leading/trailing spaces | HelloThere | | Replace Text | Replaces all instances of a specific string found in the text with another specific string | Hello Bob | | Split by Delimiter | Splits the text into fragments, using a specific character as a boundary marker | \[Hello,There] | | Concatenate | Appends additional text to the existing text value | HelloThere | ### Reference Variable Screenshot of reference variable settings This variable allows you to refer to the result of the text manipulation in future action blocks down your endpoint's flow. This variable must be assigned a custom name. Make your reference variable names as descriptive and unique as possible to prevent your endpoint flow from becoming cluttered. If a future variable is assigned the same name, the value of your reference variable will be overriden. # Match Regex Source: https://docs.avicenna.dev/guides/workshop/actions/match-regex Match or extract patterns from text using regular expressions The **Match Regex** action allows you to apply [regular expression (regex)](https://learn.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference) patterns to pieces of text to find and extract matching strings. Image *** ### Input Text The **input text** is the base text value that will be searched for the regex pattern. This can be static text or a variable. ### Pattern The **pattern** is a regex expression that will be used to search for matches in the input text. This can be static text or a variable. Refer to [this reference](https://learn.microsoft.com/en-us/dotnet/standard/base-types/regular-expression-language-quick-reference) for help writing regex. ### Reference Variables Screenshot 2026 05 26 At 4 53 17 PM These variables allow you to refer to the result of the regex match in future action blocks down your endpoint's flow. A custom name must be assigned to to refer to these variables Make your reference variable names as descriptive and unique as possible to prevent your endpoint flow from becoming cluttered. If a future variable is assigned the same name, the value of your reference variable will be overriden. The following variables will be generated based off of your custom name: * `{result.[NAME].matches}` for any matches not included in capture groups * `{result.[NAME].captures}` for any matches included in capture groups * `{result.[NAME].[CAPTURE_GROUP_NAME]}` for any matches included in named capture groups * `{result.[NAME].isMatch}` for a true/false boolean result indicating whether any match was found # Respond Source: https://docs.avicenna.dev/guides/workshop/actions/respond End a logic flow with a custom JSON response payload The **Respond** action ends your endpoint's logic flow and returns a successful response to the caller with a custom JSON payload. It is typically placed as the final block in a flow, and lets you define exactly what data gets sent back — whether that's a status code, a message, dynamic variables, or any other key-value pairs your integration requires. Respond action block *** ### JSON Response The **JSON Response** section is where you build the payload that will be returned when your endpoint is called. Each entry consists of a **key** and a **value**, which together form a field in the returned JSON object. You can add as many key-value pairs as your response requires by clicking **+ Add Key**. Each key should be a unique string that identifies the field (e.g. `success`, `status`, `message`), and each value can be static text, a number, a boolean, or a dynamic variable pulled from earlier in your flow using curly braces (e.g. `{current_time}`). | **Component** | **Description** | | ------------- | --------------------------------------------------------------------------------- | | Key | The field name in the returned JSON object (e.g. `status`, `message`) | | Value | The value for that field — can be static or a dynamic variable (e.g. `{user_id}`) | | + Add Key | Adds a new key-value pair to the response payload | | ✕ | Removes that key-value pair from the response | Use dynamic variables (wrapped in `{}`) in your value fields to return data from earlier action blocks — for example, `{current_time}` or `{user_email}`. This makes your responses far more useful than returning hardcoded values. *** ### Advanced (JSON Editor) Clicking **Advanced** opens a raw JSON editor where you can write your response payload directly instead of using the key-value fields. This is useful when you're working with a more complex or nested JSON structure that's easier to write by hand. The editor displays your current payload as valid JSON and lets you edit it freely. Any changes made here will be reflected back in the key-value view. Respond advanced JSON editor If you're unsure about your JSON syntax, use the **Need help formatting JSON?** link at the bottom of the editor — it'll point you to a formatter tool. # Send Email Source: https://docs.avicenna.dev/guides/workshop/actions/send-email Send a custom email using the Resend integration. The **Send Email** action lets you send transactional or dynamic emails directly from your endpoint flow using the Resend integration. This block runs at execution time and supports both static content and dynamic variables from previous steps. This action requires the **Resend Integration** to be configured in order to run. Your endpoint flow will ignore this block if the integration is not properly configured. Send Email Block SS *** ### To The **To** field defines the recipient's email address. You can enter a static email that will be used in all requests or use a variable for dynamic email sending per every request. ### From The **From** field defines the sender's name and email address. The syntax should be as follows: ```text theme={null} Your App Name ``` The Sender's email domain must be verified from your Resend dashboard. ### Subject The **Subject** field defines the subject line of the email. You can include dynamic variables using `{}` syntax. For example: ```text theme={null} Welcome to our platform, {params.name}! ``` ### Body The **Body** field contains the email's main content. You can write static plain text or use variables to make each request dynamic! For example: ```text theme={null} Hi {params.name}, Thank you for signing up. Best, The Team ``` # Send External Request Source: https://docs.avicenna.dev/guides/workshop/actions/send-external-request Send an HTTP request to an external endpoint The **Send External Request** action allows you to send an HTTP request an to an external, 3rd-party API and use the response information in your endpoint's flow. Screenshot2026 02 15at8 25 05AM *** ### Block Name The **block name** is the reference name for the request that will correspond to the response variables you can use in future actions. If a future block is assigned the same name, the value of your reference variable may be overriden. Below are listed the variables that can be used throughout your endpoint's flow to reference the request's response. | Variable | Description | | ----------------------- | ----------------------------------------------------------- | | `{BLOCK_NAME.body}` | Returns full response body | | `{BLOCK_NAME.status}` | Returns the request status | | `{BLOCK_NAME.body.KEY}` | Returns the value of a specific key in a JSON response body | ### Request URL The **request URL** is the URL that the API request will be sent to. Query parameters can also be included in the URL, as shown below: ```shellscript theme={null} https://example.com/api/info?name=Bobby&age=18 ``` ### Method The **method** is the type of API request that will be sent. Refer to the API provider's documentation for information on which one to choose. ### HTTP Headers The**HTTP headers** allow you to attach extra information to your request, such as authentication tokens or request metadata. Up to 10 key-value pairs may be configured per request. ### Request Body All request methods except `GET` requests also include a **request body**. This is where most extra information and inputs are placed in a request. Refer to the API provider's documentation for information on what to add. # Set Variable Source: https://docs.avicenna.dev/guides/workshop/actions/set-variable Create and store a per-execution variable for use throughout your flow. The **Set Variable** action lets you define a value for a local variable that can be reused anywhere later in your endpoint flow. Set Variable *** ### Name The **name** field defines the variable identifier. This is the key you will use when referencing the value later in the flow. For example, if you're variable's name is `points`, the reference variable will be `{local.points}`. If another **Set Variable** block uses the same name later in the flow, the previous value will be overridden. ### Value The **Value** field defines what is actually stored in the variable. This can be: * Static text (for example, `Hello world`) * A number (for example, `42`) * A boolean (`true` / `false`) * A dynamic reference (for example, `{request.body.name}`) * A computed value from previous blocks or input from a query parameter *** ## Referencing Variables To reference the value of a local se the following syntax: ```text theme={null} {local.VARIABLE_NAME} ``` For example, a variable with the name `points` can be referenced with `{local.points}`. Variables created with this block are scoped to the current execution only, and will not persist after the request is completed. *** ## Behavior & Scope Local variables are available only during the current endpoint execution and do not persist between requests. In addition, they can be overridden within a request if another **Set Variable** action uses the same identifier name. # Introduction Source: https://docs.avicenna.dev/index Hello and welcome to Avicenna's documentation and knowledge base! Avicenna Workshop Og Image 9 Whether you need a jumpstart building your first API or just need to check a quick reference while working on an existing project, you're in the right place! This documentation has been carefully crafted to meet the needs of all Avicenna builders and has plenty of clear and organized information to help make your Avicenna smoother! To explore, refer to the **Navigation Sidebar** on the left or use the **search bar (⌘K)**. Thank you for choosing Avicenna! We're committed to building the most intuitive platforms that make the experience the easiest for our users, and we keep this documentation up-to-date and a clear and organized reference for our users' diverse needs. If you need further assistance or human support, do not hesitate to join our friendly community and support Discord server: [avicenna.dev/discord](https://discord.gg/c5Zaj2PJRk)! # Endpoint Methods Source: https://docs.avicenna.dev/methods An endpoint can be set to one of five **methods**, depending on its intended use. Each of these methods and example use cases are described below. Image Note that many methods have similar or identical functionality. The biggest differences are usually in their intended use cases, as their names imply. If configured correctly, an endpoint's method may not significantly affect its functionality. ## GET Method The `GET` method is the default, most basic type of endpoint. It allows you to run workflows and respond with information. `GET` endpoints do not include request bodies, so all inputs must be in the form of [query parameters](/query-parameters). `GET` endpoints are usually used for simple data retrieval tasks, such as looking up a user's profile information. ## POST, PUT, & PATCH Methods The `POST`, `PUT`, and `PATCH` methods are all identical in functionality and can technically be used interchangeably. They allow you to receive information and run workflows based off of it. In addition to query parameters, these methods also include request bodies, allowing for much larger inputs. * `POST` endpoints are usually used for creating new information in a database. In addition, they are often used as webhook listeners. * `PUT` endpoints are usually used for completely replacing existing information in a database. * `PATCH` endpoints are usually used for selectively editing certain snippets of information in a datatbase. ## DELETE Method The `DELETE` method has similar functionality to `GET`. It allows you to run workflows and respond with a status. `DELETE` endpoints do not include request bodies, so all inputs must be in the form of [query parameters](https://docs.avicenna.dev/query-parameters). `DELETE` endpoints are usually used for deleting, archiving, or deactivating an entry of information in a database. # Query Parameters Source: https://docs.avicenna.dev/query-parameters Endpoints with configured **query parameters** allow extra information included in requests to be made available in your endpoint flow through variables. Screenshot2026 02 14at7 18 40PM Up to 10 query parameters can be configured per endpoint. Parameters are configured in key-value pairs. Here's what an example request containing query parameters would look like: ```shellscript theme={null} https://example.avicenna.run/api/my-endpoint?name=Bobby&age=22 ``` Query parameters included in a request that are not configured in the endpoint's workshop will be ignored. ### Key The parameter's **key** is its required name that will correspond do the reference variable name. For example, if the key is named "name", the reference variable will be `{params.name}`. ### Default Value The parameter's **default value** is an optional value that will be used as the its value in the event that a value is not provided in the request. If a default value is not configured and no value is provided in the request, the parameter's reference variable will return `null`. ### Reference Variable To reference the parameter's value in a request, use its **reference variable** anywhere within the endpoint's flow. The syntax for a query parameter's reference variable will always be `{params.KEY_NAME}` . # Quickstart Source: https://docs.avicenna.dev/quickstart Deploy your API and create your first endpoint with Avicenna! After you complete this guide, you'll have a live API up and running, ready for custom endpoints and integrations! If you haven't already, create an Avicenna account by navigating to the [Sign Up](https://www.avicenna.dev/signup) page. After creating an account, you'll be automatically redirected to the [Onboarding](https://www.avicenna.dev/dashboard/onboarding) page. Follow the prompts to give your project a name. Your project's name will be used only as an internal reference label for your team and will not affect your API. After naming your project, you may choose a custom subdomain for your API to be hosted on. For example, if you choose the subdomain `compass`, your API will be immediately hosted at `https://compass.avicenna.run/api`. Once you've chosen an API subdomain, changing it could cause breaking changes for your users and make previous URLs become outdated. After completing the Onboarding prompts, navigate to the main [Dashboard](https://www.avicenna.dev/dashboard) and click the **Create Endpoint**  button in the sidebar. Name your endpoint and a new Workshop will open. Time to start building! Refer to the Workshop section in the sidebar of this documentation for more help building endpoints. ## Next Steps Familiarize yourself with the Workshop layout # Tally Form Submission Listener Source: https://docs.avicenna.dev/tally-form-submission-listener By the end of this guide, you'll have a fully working webhook listener that sends an email whenever someone submits your Tally form. You can see a working version of the final product [here](https://tally.so/r/zxJLM8). This guide may include **intermediate to advanced** concepts or terminology. *** ## What You'll Need Below are the prerequisites you'll need to follow along with this guide: * a [Tally](https://tally.so) account (free) * a configured Resend integration in Avicenna (if you want to [send an email](/guides/workshop/actions/send-email)) *** ## 1. Create a Tally Form Log in to [Tally](https://tally.so) and create a new form (let's call it "Submit a Suggestion) Add a short answer or long answer question to your form (you can word the question however you wish) Image Once your form looks something like the image above, you can go ahead and publish it! ## 2. Create a Listener Endpoint From the Avicenna Dashboard, create a new `POST` endpoint (we'll name ours `/tally-listener`). Image Tally will send information about the form submission via the request body. Add the `eventId` and `data` keys to the request body.  A full example of the request body Tally sends can be found [here](https://tally.so/help/webhooks#7333898d17a247c892bd00e30e2d582b). Image Add the [Send Email action](/guides/workshop/actions/send-email) to your workflow and connect it to the base starting block. If you don't want to send an email, you can instead use a different action such as [Send External Request](/guides/workshop/actions/send-external-request) to trigger something else. Image You can customize your email's body however you like. Use the variables listed below to add content from the Tally form submission: * `{body.data.fields.0.value}` - Returns the answer to the first question in your form * `{body.eventId}` - Returns the event ID of the Tally form submission A full example and list of keys that are returned by Tally and can be accessed through variables can be found [here](https://tally.so/help/webhooks#7333898d17a247c892bd00e30e2d582b). Add a simple [Respond](/guides/workshop/actions/respond) action to tell Tally that you received the webhook. You're then ready to deploy the endpoint! Image ## 3. Configure Tally Webhook Copy the endpoint URL for your webhook listener. Image Navigate to the **Integrations** tab from the Tally settings page for your form. Click **Connect** under the "Webhooks" option. Image Paste your Avicenna listener endpoint's URL in the \*\*Endpoint URL \*\*field. If your API requires authentication, add an API key in the HTTP Headers field. Click **Connect** once you're done. Screenshot 2026 05 04 At 6 02 06 PM ## 4. All done! Try submitting a response to your Tally form and watch your Avicenna endpoint run! You can check your endpoint's logs from the Avicenna Dashboard to verify that the webhook executed. Try out a working version of this Tally setup we've made here: [https://tally.so/r/zxJLM8](https://tally.so/r/zxJLM8)! *** ## Frequently Asked Questions No, this setup works fine with Tally's free plan! Yes. Instead of the Send Email action, you can use the Send External Request action to call any third-party service or API of your choice. You can use `{body.data.fields.1.value}` for the second field, `{body.data.fields.2.value}` for the third, and so on. The full list of available keys is documented in [Tally's webhook reference](https://tally.so/help/webhooks#7333898d17a247c892bd00e30e2d582b). Authentication is optional. If your API requires it, you can add an API key in the HTTP Headers field when configuring the Tally webhook integration. # Workshop Overview Source: https://docs.avicenna.dev/workshop-overview Get familiar with Avicenna Workshop for building endpoints Build, edit, and deploy endpoints seamlessly from the Avicenna Workshop. The Workshop contains all the tools you need to fully customize and scale your API. Screenshot2026 02 17at5 17 13PM *** ## Action Pool The left sidebar of the Workshop contains a pool of all the available actions. Drag and drop an action block from the sidebar into the main workflow area to add it to your endpoint's flow. Actions are divided into different organized categories. In addition, you can search through actions using the search bar. Action Pool Sidebar SS *** ## Action Configuration The right sidebar of the Workshop contains the configuration settings for every individual action in your workflow area. Select an action (by clicking on it) to view it's respective settings. Screenshot2026 02 17at5 13 58PM *** ## Workflow Area The main workflow area in the center of the Workshop is where all of your blocks can be connected to form logic trees that will be executed in order when a request is sent to the endpoint. ### Building Logic Trees Start building your logic tree by dragging an action from the Action Pool sidebar and dropping it into the Workflow Area. You can then connect it to other blocks by dragging out from its connection nodes and dropping the connection onto another block's connection nodes. Screen Recording2026 02 17at7 14 37PM ### Action Bar The top navbar in the Workshop contains quick links to return to the main Dashboard, view your endpoint's deployment status, or save/deploy the endpoint. To view additional information about your endpoint's deployment status, click on the **Live** tag next to the endpoint path. The endpoint's full live URL will also be shown there. In addition to the Save and Deploy buttons in the Action Bar, you can use the quick keyboard shortcuts **⌘S** and **⌘D** respectively. ### Base Settings Block The base green block at the start of the logic tree contains basic settings for the endpoint, including the endpoint name, [method](/methods), and [query parameters](/query-parameters). These can be edited directly from the Action Configuration sidebar when the Base Settings block is selected. Image ### Viewing Toolbar At the bottom of the Workshop there is a small toolbar with various tools to adjust the Workshop's viewing settings, as described below: * /**Zoom:** Adjust the zoom of the Workflow Area and logic tree only. * **Fit Screen:** FIts the logic tree to fill the screen, adjusting zoom and positition as necessary. * **Tidy Up:** Adjusts scattered blocks into an organized logic tree. Screenshot2026 02 17at7 00 55PM *** ## Next Steps Learn how to collect dynamic input in endpoint flows through parameters