Firebase Realtime Database → REST

Your database,
as plain URLs.

Sanchar DB sits in front of your Firebase Realtime Database and exposes it as a clean HTTP API. No SDK to install, no auth headers to manage — just a URL and a response.

The API

Four endpoints. That's the whole surface.

Every request follows the same shape: an action, a path, and — for writes — a value. Every response is JSON with a status field you can branch on with total confidence.

GET /get/<path>

Reads a value or an entire folder — nested folders and all. Point it at any level and get everything underneath it back in one response, exactly as it's structured in the database.

Request
/get/users/henry
Response · 200
{
  "status": "success",
  "path": "users/henry",
  "data": {
    "username": "henry",
    "password": "henry2018floyd"
  }
}

Works at any depth — /get/users would return every user, each with their own nested fields.

SET /set/<path>/<key>?value=<value>

Creates or updates a single field, and creates any missing parent folders automatically. Values are always stored and returned as strings, so what you send is exactly what you get back — no silent number conversion to worry about.

Request — set a username
/set/users/henry/username?value=henry
Response · 200
{
  "status": "success",
  "message": "Data saved successfully at /users/henry/username",
  "path": "users/henry/username",
  "value": "henry"
}
Request — set a password
/set/users/henry/password?value=henry2018floyd
Response · 200
{
  "status": "success",
  "message": "Data saved successfully at /users/henry/password",
  "path": "users/henry/password",
  "value": "henry2018floyd"
}

The last segment before ?value= is the field name, so /set/users/henry/username?value=henry and /set/users/henry/password?value=henry2018floyd build up the nested record shown in the GET example above.

You can also skip ?value= entirely and put the value directly in the path — /set/users/henry/username/henry works identically. Switch to the ?value= form only when the value itself contains a slash (a URL, a date like 2024/01/15), since a plain path can't tell that slash apart from a new folder.

INFO /info/<path>

Checks whether a path exists before you commit to a read or write, and tells you whether it's a single value or a folder of children.

Request
/info/users/henry
Response · 200
{
  "status": "success",
  "exists": true,
  "path": "users/henry",
  "type": "folder",
  "items_inside": 2
}
DELETE /delete/<path>

Deletes a value or an entire folder and everything inside it. Checks the path exists first, so you always know whether something was actually removed.

Request
/delete/users/henry
Response · 200
{
  "status": "success",
  "message": "Successfully deleted /users/henry",
  "path": "users/henry"
}

Try it now

Live request console

This calls the real, deployed API. Nothing here is simulated.

/
response
Waiting for request…

Know what you'll get

Every response, before you make the call

Every response carries a status field — always one of three values — so you can branch on it with 100% predictability.

status: success

The request was valid and completed. For get/info, this can still mean "nothing exists here" — check exists or data to be sure.

status: fail

The request was understood but couldn't be completed — bad syntax, a missing value, or a path that doesn't exist for a delete. The message field says exactly why.

status: error

Something broke on the server side — a misconfiguration or an unexpected exception. These are rare and always logged with a message.