> ## Documentation Index
> Fetch the complete documentation index at: https://help.lobyco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Prompt

> In-app prompts - what they contain, the two ways to integrate them, and how interactions are recorded.

Prompts are targeted messages you put in front of a customer and expect an answer to — a consent agreement, an announcement, a required onboarding step. The service decides *which* prompts a given customer should see; you decide *how* they are displayed.

Typical uses are consent agreements the customer must accept or decline, segment-targeted announcements, onboarding steps, and time-sensitive campaign notices.

## What a prompt contains

| Part | Detail |
| - | - |
| Headline | The primary title. |
| Body | Descriptive content. |
| Image | Optional visual. |
| Actions | Accept and decline buttons, with customisable labels. |
| Metadata | Deep links, external identifiers and display configuration. |

Prompts are targeted at a **device type** — `Mobile` or `Web` — so the same customer can be shown different prompts in different channels.

## Interactions

A customer can respond in three ways, and all three are recorded.

| Interaction | Meaning |
| - | - |
| Accept | The customer agrees to the prompt. |
| Decline | The customer explicitly rejects it. |
| Close | The customer dismisses it without deciding. |

Decline and Close both go to the decline endpoint, distinguished by the action type in the body. Recording Close matters: it is what stops the same prompt reappearing forever.

<Info>
  **You do not filter prompts yourself.** The service already applies device type, membership criteria, previous interactions and active date ranges before returning anything. Render what you receive.
</Info>

## Choosing an integration pattern

| | URL-based | Native |
| - | - | - |
| Who renders the prompt | The prompt service | You |
| Who records the interaction | The prompt service | You |
| Effort to integrate | Low | Higher |
| Control over look and feel | None | Full |
| Best for | Getting live quickly | Matching your app's design |

### URL-based

<Steps>
  <Step>
    ### Ask whether anything is waiting

    Call the available-prompts endpoint for the customer. It returns a URL when there is something to show.
  </Step>

  <Step>
    ### Open it

    Navigate to the URL, or open it in a web view.
  </Step>

  <Step>
    ### Let the customer respond

    The service displays the prompt and records the outcome. The customer is redirected back to your application afterwards.
  </Step>
</Steps>

### Native

<Steps>
  <Step>
    ### Fetch the prompt details

    Call the details endpoint to get headline, body, image, button labels and metadata.
  </Step>

  <Step>
    ### Render it natively

    Build the prompt with your own UI components so it matches the rest of the app.
  </Step>

  <Step>
    ### Record the response

    Call the accept or decline endpoint when the customer responds. Send the action type so Decline and Close are distinguished.
  </Step>

  <Step>
    ### Follow the returned URL

    The response carries a navigation URL. Use it, or handle the navigation locally.
  </Step>
</Steps>

## Deep links

After a customer responds, you can send them somewhere specific. Deep link targets are configured in the prompt metadata and resolved by the service — commonly the home screen, the profile screen, or a specific activity identified by an id in the deep link parameters.

Accept and decline can each have their own destination, and either can be a deep link or an external URL.

## API reference

Endpoint documentation, including request and response examples: [Prompt](/api-reference/communication/prompt).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.