docs: added docs generated by mintlify by refrencing to /docs-legacy#91
docs: added docs generated by mintlify by refrencing to /docs-legacy#91yash-pouranik merged 1 commit intomainfrom
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
yash-pouranik
temporarily deployed
to
docs/powered-by-mintlify - urBackend-frankfrut PR #91
Render
Destroyed
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (38)
📝 WalkthroughWalkthroughThis PR adds comprehensive Mintlify documentation for urBackend, covering API reference endpoints (auth, data, storage), SDK usage guides, concept explanations (API keys, collections, RLS), security guidance, and configuration files for the documentation site. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Adds a new Mintlify documentation site for urBackend, including guides, SDK docs, and API reference pages.
Changes:
- Introduces Mintlify config (
docs.json) and a full documentation IA (Get Started / Concepts / Guides / SDK / API Reference). - Adds new MDX pages covering auth, database, storage, webhooks, security, limits, and SDK usage.
- Includes Mintlify starter-kit ancillary files (README/CONTRIBUTING/AGENTS/LICENSE/.mintignore) and an analysis snapshot.
Reviewed changes
Copilot reviewed 38 out of 38 changed files in this pull request and generated 28 comments.
Show a summary per file
| File | Description |
|---|---|
| mintlify/docs/docs.json | Defines Mintlify site settings and navigation structure. |
| mintlify/docs/index.mdx | New docs landing page with links into major sections. |
| mintlify/docs/introduction.mdx | Product overview and feature entry points. |
| mintlify/docs/quickstart.mdx | Quick start workflow for keys, collections, and first API calls. |
| mintlify/docs/security.mdx | Security model overview (keys, injection, rate limiting, domains). |
| mintlify/docs/limits-and-quotas.mdx | Documented service limits and common HTTP status codes. |
| mintlify/docs/concepts/api-keys.mdx | Explains pk/sk key usage and RLS interaction. |
| mintlify/docs/concepts/collections-schemas.mdx | Explains collections, schema modes, and field types. |
| mintlify/docs/concepts/row-level-security.mdx | Explains RLS behavior, modes, and examples. |
| mintlify/docs/guides/authentication.mdx | End-user auth flows using /api/userAuth/* endpoints. |
| mintlify/docs/guides/social-auth.mdx | OAuth social login setup and callback/exchange flow. |
| mintlify/docs/guides/database.mdx | REST CRUD + filtering/pagination docs for data API. |
| mintlify/docs/guides/storage.mdx | REST storage upload/delete guide. |
| mintlify/docs/guides/webhooks.mdx | Webhook payload/signature verification and retry guidance. |
| mintlify/docs/sdk/overview.mdx | SDK install + initialization + error handling overview. |
| mintlify/docs/sdk/auth.mdx | SDK auth module methods and usage. |
| mintlify/docs/sdk/database.mdx | SDK database module methods and usage. |
| mintlify/docs/sdk/storage.mdx | SDK storage module methods and usage. |
| mintlify/docs/api-reference/overview.mdx | API base URL, auth headers, response format, endpoint index. |
| mintlify/docs/api-reference/auth/signup.mdx | API reference for signup endpoint. |
| mintlify/docs/api-reference/auth/login.mdx | API reference for login endpoint. |
| mintlify/docs/api-reference/auth/me.mdx | API reference for me + public profile endpoints. |
| mintlify/docs/api-reference/auth/refresh-token.mdx | API reference for refresh-token endpoint. |
| mintlify/docs/api-reference/auth/logout.mdx | API reference for logout endpoint. |
| mintlify/docs/api-reference/auth/social.mdx | API reference for social auth start + exchange endpoints. |
| mintlify/docs/api-reference/data/get-all.mdx | API reference for listing documents. |
| mintlify/docs/api-reference/data/get-one.mdx | API reference for fetching a single document. |
| mintlify/docs/api-reference/data/insert.mdx | API reference for inserting documents. |
| mintlify/docs/api-reference/data/update.mdx | API reference for PUT/PATCH updates. |
| mintlify/docs/api-reference/data/delete.mdx | API reference for deleting documents. |
| mintlify/docs/api-reference/storage/upload.mdx | API reference for storage upload. |
| mintlify/docs/api-reference/storage/delete.mdx | API reference for storage delete. |
| mintlify/docs/.mintignore | Mintlify ignore rules (drafts, etc.). |
| mintlify/docs/.atlas-analysis.json | Generated Mintlify/Atlas analysis snapshot. |
| mintlify/docs/README.md | Mintlify starter-kit README template. |
| mintlify/docs/CONTRIBUTING.md | Mintlify starter-kit contributing template. |
| mintlify/docs/AGENTS.md | Mintlify agent guidance template. |
| mintlify/docs/LICENSE | Mintlify starter-kit license file. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| window.location.href = `${API_URL}/api/userAuth/social/github/start?x-api-key=${API_KEY}`; | ||
| }; | ||
|
|
||
| const handleGoogleLogin = () => { | ||
| window.location.href = `${API_URL}/api/userAuth/social/google/start?x-api-key=${API_KEY}`; |
There was a problem hiding this comment.
The OAuth start URLs here use ?x-api-key=..., but the public API middleware only reads a publishable key from the key query parameter (and strips req.query.key). Using x-api-key in the query string will be ignored and the redirect will 401. Update the examples to use ?key=pk_live_... (and keep secret keys in headers only).
| window.location.href = `${API_URL}/api/userAuth/social/github/start?x-api-key=${API_KEY}`; | |
| }; | |
| const handleGoogleLogin = () => { | |
| window.location.href = `${API_URL}/api/userAuth/social/google/start?x-api-key=${API_KEY}`; | |
| window.location.href = `${API_URL}/api/userAuth/social/github/start?key=${API_KEY}`; | |
| }; | |
| const handleGoogleLogin = () => { | |
| window.location.href = `${API_URL}/api/userAuth/social/google/start?key=${API_KEY}`; |
| Redirects the user's browser to the provider login page. Because this is a browser redirect (not a `fetch` call), pass your API key as a query parameter. | ||
|
|
||
| <ParamField path="provider" type="string" required> | ||
| OAuth provider name. Accepted values: `github`, `google`. | ||
| </ParamField> | ||
|
|
||
| <ParamField query="x-api-key" type="string" required> | ||
| Your `pk_live_…` key. Can also be sent as a header if you are making a non-redirect request. | ||
| </ParamField> | ||
|
|
There was a problem hiding this comment.
This API reference documents the OAuth start endpoint as taking x-api-key in the query string, but the server expects the publishable key in ?key= (query param) for browser redirects. Update the parameter name and the code examples accordingly or the documented flow will fail with 401.
| Access storage methods via `client.storage`. Uploaded files are served from a public CDN — no extra configuration required. | ||
|
|
||
| <Note> | ||
| Storage operations accept both `pk_live_...` and `sk_live_...` keys. Use `pk_live_...` in browser code for user-initiated uploads, and `sk_live_...` for server-side uploads. Never expose your secret key in browser code. | ||
| </Note> |
There was a problem hiding this comment.
This note says Storage operations accept both pk_live_... and sk_live_... keys, but /api/storage/* routes are protected by requireSecretKey in the public API. With the current backend, storage calls require sk_live_... and will 403 for publishable keys—please update the SDK docs accordingly (or change the backend to actually allow pk-live uploads).
| ## Limits | ||
|
|
||
| | Limit | Value | | ||
| |---|---| | ||
| | Max file size | 5 MB per file | | ||
| | Total storage per project | 100 MB | | ||
|
|
||
| <Note> | ||
| Uploads that exceed 5 MB are rejected with a `StorageError`. Check `file.size` before calling `upload()` if you need to show a friendly error to your users. | ||
| </Note> |
There was a problem hiding this comment.
The limits section claims the SDK upload limit is 5 MB, but the server enforces a 10 MB max file size for /api/storage/upload (multer + controller check). The SDK does not appear to enforce 5 MB client-side either, so this will mislead users—update to the actual limit or document any planned SDK-side restriction.
| const res = await fetch('https://api.ub.bitbros.in/api/storage/upload', { | ||
| method: 'POST', | ||
| headers: { | ||
| 'x-api-key': 'YOUR_KEY' | ||
| }, | ||
| body: formData | ||
| }); |
There was a problem hiding this comment.
The storage guide implies any API key can be used ('YOUR_KEY'), but the public API storage routes require a secret key (sk_live_...) via requireSecretKey. Document this explicitly; otherwise users will try pk_live_... from the browser and get 403.
| ## deleteFile | ||
|
|
||
| Delete a previously uploaded file by its storage path. | ||
|
|
||
| ```typescript | ||
| deleteFile(path: string): Promise<{ deleted: boolean }> | ||
| ``` | ||
|
|
||
| **Parameters** | ||
|
|
||
| | Name | Type | Required | Description | | ||
| |---|---|---|---| | ||
| | `path` | `string` | Yes | The `path` returned by `upload()`. | | ||
|
|
||
| **Example** | ||
|
|
||
| ```typescript | ||
| // Retrieve the stored path | ||
| const image = await client.db.getOne('product_images', id); | ||
|
|
||
| const result = await client.storage.deleteFile(image.path); | ||
| console.log(result.deleted); // true | ||
| ``` |
There was a problem hiding this comment.
deleteFile() is documented as returning { deleted: boolean }, but the current /api/storage/file handler responds with { message: "File deleted successfully" } on success (no deleted flag). Either adjust the docs/types to match the API, or update the API response to include the documented boolean so SDK callers can rely on it.
| Your webhook URL is public, so anyone could send data to it. urBackend signs every payload with your signing secret using HMAC-SHA256 and includes the signature in the `X-urBackend-Signature` header. Always verify this signature before processing the event. | ||
|
|
||
| ### How verification works | ||
|
|
||
| 1. urBackend computes `HMAC-SHA256(signingSecret, JSON.stringify(requestBody))`. | ||
| 2. The resulting hex digest is sent in `X-urBackend-Signature`. | ||
| 3. Your server performs the same computation and compares the result. | ||
| 4. If the signatures match, the request is authentic. | ||
|
|
||
| ### Node.js / Express example | ||
|
|
||
| ```javascript | ||
| const express = require('express'); | ||
| const crypto = require('crypto'); | ||
| const app = express(); | ||
|
|
||
| const URBACKEND_WEBHOOK_SECRET = process.env.URBACKEND_WEBHOOK_SECRET; | ||
|
|
||
| app.post('/urbackend-webhook', express.json(), (req, res) => { | ||
| // 1. Extract the signature header sent by urBackend | ||
| const signature = req.headers['x-urbackend-signature']; | ||
|
|
||
| // 2. Serialize the request body | ||
| const payload = JSON.stringify(req.body); | ||
|
|
||
| // 3. Compute the expected HMAC-SHA256 digest | ||
| const expectedSignature = crypto | ||
| .createHmac('sha256', URBACKEND_WEBHOOK_SECRET) | ||
| .update(payload) | ||
| .digest('hex'); | ||
|
|
||
| // 4. Compare signatures — reject if they don't match | ||
| if (!signature || signature !== expectedSignature) { | ||
| console.error('Webhook verification failed — potential spoofing attempt'); | ||
| return res.status(401).send('Invalid signature'); | ||
| } |
There was a problem hiding this comment.
The webhook signature example computes/compares a raw hex digest, but the backend sends X-urBackend-Signature in the format sha256=<hex> (including the sha256= prefix). As written, signature !== expectedSignature will always fail. Update the docs to either include the prefix in the computed value or strip it before comparison.
| Always respond with a `2xx` status code as quickly as possible. If your endpoint takes longer than 10 seconds to respond or returns a `4xx`/`5xx` status, urBackend marks the delivery as failed and will retry it. | ||
| </Warning> | ||
|
|
||
| ## Retry logic | ||
|
|
||
| If a delivery fails (timeout over 10 seconds, or a `4xx`/`5xx` response), urBackend will automatically retry. You can inspect every delivery attempt — including the exact payload sent and the response received — in the **Delivery History** panel of your webhook's dashboard page. You can also manually replay failed deliveries from there. |
There was a problem hiding this comment.
This warning states failures include a timeout over 10 seconds, but the current webhook delivery worker uses a 30s AbortController timeout. Update the documented timeout threshold so it matches actual delivery behavior (or adjust the implementation to 10s if that’s the intended contract).
| Always respond with a `2xx` status code as quickly as possible. If your endpoint takes longer than 10 seconds to respond or returns a `4xx`/`5xx` status, urBackend marks the delivery as failed and will retry it. | |
| </Warning> | |
| ## Retry logic | |
| If a delivery fails (timeout over 10 seconds, or a `4xx`/`5xx` response), urBackend will automatically retry. You can inspect every delivery attempt — including the exact payload sent and the response received — in the **Delivery History** panel of your webhook's dashboard page. You can also manually replay failed deliveries from there. | |
| Always respond with a `2xx` status code as quickly as possible. If your endpoint takes longer than 30 seconds to respond or returns a `4xx`/`5xx` status, urBackend marks the delivery as failed and will retry it. | |
| </Warning> | |
| ## Retry logic | |
| If a delivery fails (timeout over 30 seconds, or a `4xx`/`5xx` response), urBackend will automatically retry. You can inspect every delivery attempt — including the exact payload sent and the response received — in the **Delivery History** panel of your webhook's dashboard page. You can also manually replay failed deliveries from there. |
| **Endpoint:** `POST /api/userAuth/verify-email` | ||
|
|
||
| ```javascript | ||
| const res = await fetch('https://api.ub.bitbros.in/api/userAuth/verify-email', { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| 'x-api-key': 'pk_live_YOUR_KEY' | ||
| }, | ||
| body: JSON.stringify({ token: 'VERIFICATION_TOKEN_FROM_EMAIL' }) | ||
| }); | ||
| ``` |
There was a problem hiding this comment.
The verify-email example posts { token: ... }, but the current /api/userAuth/verify-email endpoint expects { email, otp } (OTP stored in Redis). Please update the request body example/description to match the actual API contract.
| <Step title="Reset the password"> | ||
| Submit the reset token (from the email link) along with the new password. | ||
|
|
||
| **Endpoint:** `POST /api/userAuth/reset-password` | ||
|
|
||
| ```javascript | ||
| const res = await fetch('https://api.ub.bitbros.in/api/userAuth/reset-password', { | ||
| method: 'POST', | ||
| headers: { | ||
| 'Content-Type': 'application/json', | ||
| 'x-api-key': 'pk_live_YOUR_KEY' | ||
| }, | ||
| body: JSON.stringify({ | ||
| token: 'RESET_TOKEN_FROM_EMAIL', | ||
| newPassword: 'newSecurePassword456' | ||
| }) | ||
| }); | ||
| ``` |
There was a problem hiding this comment.
The reset-password example uses { token, newPassword }, but the current /api/userAuth/reset-password endpoint expects { email, otp, newPassword }. Update the docs so integrators send the OTP code they received, not a token field.
urbackend docs generated by mintlify.
Built with ❤️ for urBackend.
Summary by CodeRabbit
Release Notes