# Connecting Your Service

In the previous step you created your post data. Now it is time to show that data to real users. Because WEEGLOO takes care of storing and managing the data, how you present it through a service is entirely your choice. You can build a web application, expand it into a mobile app, or run both side by side. The key point is that you can fetch the data through the RESTful API that WEEGLOO provides and use it in whatever form you want.

In this example you build the Tech Blog as a website. Visitors view posts in a web browser, and you build the screen (front-end) they see. The static web files you create this way can be deployed with WEEGLOO's *Web Hosting* feature.

A mobile app connects to the same backend without any changes. Storing the data, taking in members, and showing each person only their own content works the same way on the web and in an app. You can see a complete example where an app and a web page share a single backend, from start to finish, in [Running Tracker Service](/getting-started/examples/running-tracker.md).

## Issuing a Read-Only Token {#issuing-a-read-only-token}

To call the WEEGLOO API you need an Access Token for authentication. In this example you use a *Delivery Access Token*, a read-only token meant for showing posts to visitors, together with the CDA (Content Delivery API), the API that delivers published content.

Before you create the token, you first need to decide what data it can access by using a *SpaceRole*. For security, you create a *SpaceRole* that grants read access only to the `Article` *Content Type* you made earlier. This way the token can do nothing other than read posts.

1. In the left menu, click **Roles & Permissions**.
2. Click **Create** and enter a role name. For example: `Article Read-Only`.
3. Allow only **Read** for **Content** and **Content Type** of `Article`. Do not turn on any other permission.
4. Save it with **Save**.

![SpaceRole settings screen granting read-only permission to Article](/_img/en-US/getting-started/quick-start/images/intro-4-01-role.webp)

For more details on *SpaceRole* settings, see [Roles and Permissions](/getting-started/core-concepts/access-and-permissions/role-and-permissions.md).

Now you create a *Delivery Access Token* that holds this *SpaceRole*.

1. In the left menu, click **Delivery Access Tokens**.
2. Click **Create** at the top right of the list. The **Create Delivery Access Token** screen opens.
3. Enter `Tech Blog Web` in the **Name** field.
4. In **SpaceRole**, choose the `Article Read-Only` you created earlier.
5. Leave **Allowed referrers** on its initial value, **No restriction**. Listing addresses there means only requests coming from those addresses get through, so once the address of your Tech Blog site is settled you can come back and narrow this token to that site alone.
6. Click the **Create** button at the top right of the screen to issue it.

![The Create Delivery Access Token screen. "Tech Blog Web" is entered in the Name field, "Article Read-Only" is chosen in SpaceRole, Allowed referrers is "No restriction", and the Create button is at the top right](/_img/en-US/getting-started/quick-start/images/intro-4-02-token.webp)

Once you finish issuing, you move to that token's detail screen. The token value sits in the **Token** field under **Basic information**, and clicking the copy button on the left of the field copies the value. You can come back to this screen and copy the value again at any time. Still, this value is a secret, so store it somewhere safe. Because it can be exposed all the way to the visitor's browser, it is important to narrow its scope with a read-only *SpaceRole* as shown above.

For more details on the *Delivery Access Token* and the **Allowed referrers** setting, see [Tokens](/getting-started/core-concepts/access-and-permissions/token.md#allowed-referrer).

## Fetching Your Post Data {#fetching-your-post-data}

Now you actually call the API that fetches your posts. For authentication, put the *Delivery Access Token* value you created earlier into the **Authorization** header using the Bearer scheme.

```
Authorization: Bearer <Delivery Access Token>
```

| API | Method | Path | Params |
|---|---|---|---|
| CDA | GET | `/v1/spaces/{spaceId}/content-types/{contentTypeId}/contents` | `?order=-sys.createdAt,sys.id` |

This API fetches the list of `Article` *Content* within a specific *Space*. The `order` option sorts them newest first, and the `include` option lets you fetch linked data along with them.

The first time you call it, you may get no data at all. That is because the *Content* you created has not been published yet. WEEGLOO adds a publishing step to separate the data you are still working on from the data shown to visitors. Once you publish the *Content* and call the API again, the posts appear.

```json
{
    "sys": { "type": "TotalPageResponse" },
    "limit": 15,
    "totalCount": 1,
    "items": [
        {
            "sys": {
                "id": "3trmXRkRjC1x4J9h2om4Qh41o7sejd",
                "type": "Content",
                "space": { "sys": { "id": "ep8f7qJY", "type": "Refer", "targetType": "Space" } },
                "contentType": { "sys": { "id": "3trmXRkRjC1x4J9h2om4QZv0jC58Nv", "type": "Refer", "targetType": "ContentType" } },
                "createdAt": "2026-06-21T15:38:22.630Z",
                "updatedAt": "2026-06-21T15:38:22.630Z",
                "revision": 1
            },
            "fields": {
                "title": "Building a Headless Blog with WEEGLOO",
                "body": "WEEGLOO lets you define your content structure once and deliver it anywhere through a REST API. In this post we model an Article, write our first entry, and fetch it from a web app, with no backend server to build or maintain.",
                "category": "Web"
            }
        }
    ],
    "links": {
        "self": "/v1/spaces/ep8f7qJY/content-types/3trmXRkRjC1x4J9h2om4QZv0jC58Nv/contents?order=-sys.createdAt,sys.id"
    }
}
```

For detailed API usage and options, see the [API Reference](/api/reference/common.md).

## Multilingual Support {#multilingual-support}

Going one step further, you can offer your posts in several languages. WEEGLOO provides the *Locale* feature so you can manage a single piece of content in multiple languages.

First, add a new language in the *Locale* settings. Here you add `Korean` and set the **Fallback** language to `English`, which is shown instead when a value is missing. A fallback is the language shown in place of another when that language has no value.

Then, when you go to the *Content* you created earlier, you will see that a field for entering per-language values has appeared for each *Field*. This is how you manage the content of the same post separately by language. Note that to use this feature, you must turn on the multilingual option for that *Field* in the *Content Type* beforehand.

![A post's Field showing input boxes for both English (en-US) and Korean (ko-KR)](/_img/en-US/getting-started/quick-start/images/intro-4-03-localized.webp)

For more details on multilingual support, see [Managing Localization](/getting-started/core-concepts/content/localization.md).

This is how you can build a web service that supports multiple languages from a single data structure. Now that you have completed basic content retrieval and multilingual handling, the next step looks at the collaboration features that let several people write and manage content together.

- [Collaborating](/getting-started/quick-start/intro-5.md): Invite several people to a *Space* and divide roles to manage content together.