NocoDB is the structured-data layer that sits alongside WeCareRemote. While the AI assistant handles unstructured conversation, the blog handles long-form content, and the recordings backend handles video — NocoDB handles everything that fits naturally into rows and columns: cases, contacts, resources, referrals, eligibility checklists, content calendars. NGO staff interact with NocoDB through a spreadsheet-style web UI. Other parts of the stack — the AI assistant, n8n workflows, the blog — read and write the same tables through NocoDB’s REST API.Documentation Index
Fetch the complete documentation index at: https://docs.wcr.is/llms.txt
Use this file to discover all available pages before exploring further.
What NocoDB is used for
Typical tables in a WeCareRemote NocoDB deployment:| Table | Purpose |
|---|---|
cases | One row per refugee case: assigned NGO, status, last contact, summary |
contacts | Refugees and NGO staff, linked to WeCareRemote user IDs |
services | Catalogue of services and resources the AI assistant can reference |
recordings | Index of Jitsi meeting recordings with case linkage |
referrals | Hand-offs between NGOs, with timestamps and notes |
content_calendar | Blog posts planned and published, owners, target audience |
How NocoDB connects to WeCareRemote
NocoDB is not authenticated through WeCareRemote’s JWT. Instead, NocoDB issues its own API tokens, which other services (n8n, the AI assistant, custom scripts) attach to their requests.- Direct from n8n — n8n’s built-in NocoDB node handles credentials and CRUD. Use this for most automation.
- Direct from the AI assistant — when your organization wires up a NocoDB-backed knowledge source, the assistant can query NocoDB rows the same way it queries any other knowledge base.
Setting up NocoDB
Before you begin
You need:- A running NocoDB instance reachable from n8n and from any service that needs to query it
- A NocoDB workspace and base created for WeCareRemote
- An NGO admin who can issue API tokens
Issuing an API token
Name and copy the token
Give the token a descriptive name (for example,
wcr-n8n-prod) and copy the generated value — NocoDB shows it only once.Designing a case table
A minimalcases table works well as a starting point:
| Column | Type | Notes |
|---|---|---|
id | Auto Number | Primary key |
thread_id | Single Line Text | Matches the AI assistant thread_id |
refugee_email | Links to the WeCareRemote user | |
assigned_ngo | Single Select | NGO responsible for the case |
status | Single Select | new, in_progress, waiting, closed |
topic | Single Select | housing, legal, health, education, other |
summary | Long Text | Short human-readable summary |
last_contact_at | Date Time | Updated on every interaction |
created_at | Created Time | Auto-managed by NocoDB |
contacts table, attachments for documents, and rollups for case counts per NGO.
Reading and writing rows via API
NocoDB exposes a REST API per table. The endpoint pattern is:Example: create a case from a webhook
Example: list cases filtered by status
offset and limit query parameters when reading large datasets.
Linking NocoDB to the AI assistant
To let the AI assistant reference NocoDB content (for example, the catalogue of services in aservices table), your administrator can connect NocoDB as a knowledge source. The mechanism depends on which AI model and retrieval setup your deployment uses, but the high-level flow is:
Expose the data
Make the relevant NocoDB table queryable — either through the NocoDB REST API with a scoped token, or by syncing rows into the assistant’s vector store.
Configure the assistant
In the WeCareRemote AI assistant configuration, register the NocoDB endpoint (or the synced index) as a retrieval source.
Knowledge-source configuration is administrator-only. If you want to expose a NocoDB table to the assistant, contact your WeCareRemote administrator with the table name and the columns the assistant should be able to read.
Security and best practices
- Use scoped tokens. NocoDB tokens can be scoped to specific bases. Create separate tokens per integration so a leaked token has a small blast radius.
- Mirror the JWT role model. Decide which NocoDB users correspond to
blogvsorg_adminand grant table permissions accordingly. - Audit changes. NocoDB’s row history makes it easy to see who changed what; turn on audit logs in production.
- Avoid storing secrets in rows. NocoDB is the wrong place for credentials, raw JWTs, or other sensitive material.
- Back up regularly. A nightly export of critical tables to object storage protects you against accidental deletions.
Troubleshooting
The API returns 401 Unauthorized
The API returns 401 Unauthorized
POST returns 422 Unprocessable Entity
POST returns 422 Unprocessable Entity
A column type does not match. Single Select columns reject values that are not in the option list; date columns reject strings that are not ISO 8601. Inspect the response body for the offending field.
Rows are missing from API responses
Rows are missing from API responses
NocoDB paginates by default (often 25 rows). Pass a higher
limit or iterate with offset to fetch the full table.n8n NocoDB node cannot find the table
n8n NocoDB node cannot find the table
The node lists tables by base. Make sure the base ID in the credentials matches the base that contains your table. Re-authenticating sometimes refreshes the table list.
Where to go next
n8n integration
Wire NocoDB into automated workflows triggered by WeCareRemote events.
Platform overview
See where NocoDB and n8n fit in the overall WeCareRemote architecture.