1. INTRODUÇÃO
Esta documentação tem como finalidade prover informações sobre a forma de acesso aos dados do SPALLA por meio da API e integração.
URL Base
A API deve ser instalada no servidor do cliente como um serviço do SPALLA, para isto deve-se atribuir as configurações da BASE DE DADOS de integração, a Porta de Comunicação e o Tipo de Protocolo de Transferência a ser utilizado nas requisições sendo eles HTTP ou HTTPS.
A Url Base da API possui a seguinte estrutura
| Protocolo | Endereço | Porta | Path Raiz |
|---|---|---|---|
| https | api.apelido.spalla.app | 443 | /root |
Exemplo de URL Base da API:
URL Completa da API:
https://api.apelido.spalla.app:443/root
Observação: os endereços, portas e tokens utilizados nesta documentação são exemplos genéricos. Substitua api.apelido.spalla.app, a porta e o token <SEU_TOKEN_AQUI> pelos valores reais fornecidos para a sua instalação do SPALLA.
Estrutura da URL:
# Formato Geral
https://api.apelido.spalla.app:55002/root
# URL Base (sem o path /root)
https://api.apelido.spalla.app:443
# Observação:
# - Quando a porta é 443 (HTTPS padrão) ou 80 (HTTP padrão), ela não aparece na URL
# - Exemplos: https://api.apelido.spalla.app/root (porta 443 implícita)
2. ENDPOINTS COM AUTENTICAÇÃO
A API Spalla oferece duas formas independentes de autenticação. Escolha apenas uma; elas não são combinadas na mesma requisição.
| Forma | Como funciona | Validade | Quando usar |
|---|---|---|---|
A) clientNonce + sessionSignature(ver item 2) |
Dois passos: (1) obter clientNonce com o login do usuário; (2) obter sessionSignature combinando clientNonce + senha. O sessionSignature é enviado em todas as requisições seguintes. |
Temporária: expira em 5 minutos de inatividade. Após expirar é necessário gerar um novo sessionSignature. |
Aplicações que fazem login interativo com usuário e senha (ex.: app mobile Spalla, software que exige autenticação por sessão). |
B) userToken(ver item 3) |
Chave permanente cadastrada para um usuário específico de integração. Enviada em cada requisição via QueryParam ou HEADER. |
Permanente: não expira por tempo. Só perde validade se for revogada/substituída manualmente no cadastro do usuário de integração. | Integrações máquina-a-máquina (sistemas terceiros, BI, ETL, automações). É a forma recomendada para integradores que rodam sem supervisão humana. |
Em resumo:
- Use A (
sessionSignature) quando houver login de usuário final com senha. - Use B (
userToken) para qualquer integração automatizada (é o caminho mais simples e estável). - As duas formas dão acesso aos mesmos endpoints e aos mesmos recursos —
userTokensubstitui completamentesessionSignature. - Nunca envie
sessionSignatureeuserTokenna mesma requisição. Escolha uma forma por integração.
A seguir, a documentação detalhada de cada uma.
clientNonce
Este endPoint fornece um ID único para que seja executada uma comunicação direta com os dados a aplicação SPALLA, ele deve ser executado sempre antes da autenticação para que seja possível obter o ID único de Autenticação que será utilizado no login.
O ClientNonce é um hash único gerado a partir de um valor aleatório e do login do usuário, ele é utilizado para garantir a segurança da comunicação entre o cliente e o servidor.
| Tipo | Parâmetro | Descrição |
|---|---|---|
| Query | UserName | Login do Usuário Spalla |
Exemplo:
# Exemplo de Requisição para Geração do ClientNonce
https://api.apelido.spalla.app:443/root/clientNonce?UserName=SUPORTE
Response:
{
"result": "66f4966d5b78de54f0ffdcb9fd5b4db5c1a1e4012ebfb81ef343929e42b2c512"
}
SessionSignature
O SessionSignature é o método de autenticação da API, ele é gerado a partir do ClientNonce e do Password do usuário, ele é utilizado para assinar a sessão do usuário garantindo assim a autenticação do mesmo para a utilização dos demais endPoints.
A sessão de usuário assinada com o SessionSignature tem um tempo de expiração de 5 minutos em caso de inatividade, após este tempo é necessário gerar um novo SessionSignature.
| Tipo | Params | Descrição |
|---|---|---|
| Query | UserName | Login do Usuário Mobile |
| Query | PassWord | Senha do Usuário Mobile |
| Query | ClientNonce | ClientNonce gerado na etapa anterior |
Exemplo:
# Exemplo de Requisição para Geração do SessionSignature
https://api.apelido.spalla.app:443/Auth?UserName=SUPORTE&PassWord=123456&ClientNonce=66f4966d5b78de54f0ffdcb9fd5b4db5c1a1e4012ebfb81ef343929e42b2c512
Response:
{
"usuario": "SUPORTE",
"timeout": 60,
"session_signature": "00021d4a4142ffd2993007e514df8005685ce05f6aae641e3df54ed7055ace6adc6a2a11"
}
3. ENDPOINTS COM CHAVE DE INTEGRAÇÃO
Para uma integração com aplicações de forma mais prática também disponibilizamos um endPoint um pouco mais simples que exige apenas o parâmetro userToken, este endPoint possui todos os recursos já disponibilizados porém existe apenas uma chave de acesso única que deve ser cadastrada para o usuário. Esta chave de acesso está vinculada a um usuário que será liberado para o integrador e estará vinculada a um conjunto de recursos que atender ao escopo da integração
O userToken pode ser informado tanto como QueryParam na requisição quanto no HEADER, sendo que caso exista a informação como QueryParam ela ignora o HEADER, e caso não exista ai ela passa a buscar pelo HEADER
| Tipo | Parâmetro | Descrição |
|---|---|---|
| Query | userToken | Token de Acesso o Usuário da Integração |
| HEADER | userToken | Token de Acesso o Usuário da Integração |
4. MÉTODOS
ATENÇÃO - ARQUITETURA UNIFICADA:
A API Spalla utiliza uma arquitetura de endpoint unificado. O método HTTP padrão para todas as requisições é PATCH. Para operações de gravação (POST, PUT, DELETE, PATCH no body JSON), o uso do método HTTP PATCH é obrigatório. Para operações de leitura (GET no body JSON), caso o software utilizado possua restrições quanto ao uso do método PATCH (ex: PowerBI), os métodos POST ou GET podem ser utilizados como alternativa.
O método HTTP informado na URL é independente da operação SQL a ser realizada. A operação real (consulta, inserção, atualização, exclusão ou execução de procedure) é determinada exclusivamente pelo campo "method" dentro do corpo JSON da requisição.
Como Funciona a Estrutura de Requisições
A API utiliza um conceito diferente do padrão REST tradicional. O método HTTP informado no cabeçalho da requisição não determina a operação que será executada no banco de dados. Em vez disso, a operação real é definida pelo campo "method" dentro do corpo JSON da requisição.
Estrutura Geral das Requisições:
| Componente | Descrição | Exemplo |
|---|---|---|
| Método HTTP | Padrão: PATCH (obrigatório para gravação). Para leitura, POST ou GET podem ser usados como alternativa em softwares com restrição ao PATCH (ex: PowerBI) | PATCH |
| Endpoint | Sempre o mesmo para todas as operações | /root/integrador |
| Autenticação | Via header userToken ou sessionSignature |
userToken: <SEU_TOKEN_AQUI> |
| Body JSON | Contém o campo "method" com a operação SQL real |
{ "method": "GET", ... } |
Exemplo Visual da Arquitetura:
# EXEMPLO 1: Consulta de dados (leitura)
# O método HTTP padrão é PATCH. Para leitura, POST ou GET podem ser usados como alternativa
Requisição HTTP:
Método HTTP: PATCH (padrão) ou POST/GET (alternativa para leitura)
URL: https://api.apelido.spalla.app:443/root/integrador
Header: userToken: <SEU_TOKEN_AQUI>
Body: {
"method": "GET", <-- Método SQL (operação real)
"objectType": "TABLE",
"objectName": "CLIFOR"
}
# EXEMPLO 2: Inserção de dados (gravação)
# Para gravação, o método HTTP PATCH é obrigatório
Requisição HTTP:
Método HTTP: PATCH (obrigatório para gravação)
URL: https://api.apelido.spalla.app:443/root/integrador
Header: userToken: <SEU_TOKEN_AQUI>
Body: {
"method": "POST", <-- Método SQL (operação real)
"objectType": "TABLE",
"objectName": "CLIFOR",
"dataFields": [...]
}
RESUMO IMPORTANTE:
- O método HTTP padrão para todas as requisições é PATCH
- Para operações de gravação (POST, PUT, DELETE, PATCH no body), o método HTTP PATCH é obrigatório
- Para operações de leitura (GET no body), softwares com restrição ao PATCH (ex: PowerBI) podem usar POST ou GET como alternativa
- O método real (GET, POST, PUT, DELETE, PATCH) está no campo
"method"do body JSON - A operação SQL executada é determinada exclusivamente pelo campo
"method"no JSON - Todas as requisições são enviadas para o mesmo endpoint:
/root/integrador
Métodos SQL Disponíveis (Campo "method" no Body)
Abaixo segue a documentação dos métodos SQL que podem ser especificados no campo "method" do corpo JSON para acesso aos dados do SPALLA:
| Método SQL | Operação | Objetos Suportados |
|---|---|---|
GET |
Consulta de dados (SELECT) | TABLE, VIEW, FUNCTION, PROCEDURE RESULT |
POST |
Inserção de dados (INSERT) | TABLE |
PUT |
Atualização de dados (UPDATE) | TABLE |
DELETE |
Exclusão de dados (DELETE) | TABLE |
PATCH |
Execução de procedures e functions | PROCEDURE, FUNCTION |
Diferença entre PROCEDURE e PROCEDURE RESULT:
PROCEDURE— representa uma procedure tradicional do banco de dados: executa código (regras de negócio, atualizações, rotinas) mas não retorna um conjunto de dados como resultado. Utilizada pelo métodoPATCH.PROCEDURE RESULT— representa uma procedure que executa as mesmas operações de uma procedure tradicional, mas retorna um conjunto de dados específico (status de sucesso ou falha, um valor, uma lista de registros ou qualquer outro resultado necessário para a continuidade do fluxo da aplicação). Utilizada pelo métodoGET.- Em ambos os casos o objeto físico no banco de dados é uma stored procedure; a diferença está apenas na forma como a API interpreta o retorno — execução pura (
PROCEDURE) ou retorno estruturado de dados (PROCEDURE RESULT).
Tipos de Dados e Formatação de Valores
Regras para formatar os valores enviados em dataFields, params, where e having nos métodos POST, PUT, DELETE e PATCH. A API converte internamente todos os valores recebidos em texto antes de aplicar ao banco de dados.
| Tipo no SAP SQL Anywhere | Formato JSON aceito | Exemplo |
|---|---|---|
integer, numeric, decimal, float, double |
Número JSON ou string. Ponto como separador decimal. Sem separador de milhar. Sem símbolo de moeda. | 1234 ou "1234.56" |
date (somente data) |
String no formato ISO-8601 "YYYY-MM-DD". |
"2026-04-21" |
timestamp (data e hora) |
String no formato ISO-8601 "YYYY-MM-DDTHH:MM:SS" (preferencial). Frações de segundo opcionais (.SSS). O formato alternativo "YYYY-MM-DD HH:MM:SS" também é aceito. Informações de fuso horário são ignoradas — usar sempre o horário do servidor. |
"2026-04-21T12:05:13" ou "2026-04-21T12:05:13.000" |
time (somente hora) |
String no formato "HH:MM:SS". |
"12:05:13" |
varchar, long varchar, char |
String JSON. | "Texto qualquer" |
long binary, binary (BLOB) |
String com o conteúdo em Base64. O objeto em dataFields deve incluir "fieldType": "ftBlob". |
{ "name": "ARQUIVO", "fieldType": "ftBlob", "value": "U1BBTExB..." } |
| Valor nulo | Literal JSON null ou string "NULL" (case-insensitive). |
null ou "NULL" |
Observações importantes:
- Para colunas numéricas, enviar
"value": 1ou"value": "1"produz o mesmo efeito — a API converte o valor para string antes de aplicar. - Valores monetários devem usar ponto como separador decimal, sem separador de milhar e sem símbolo de moeda. Correto:
"1234.56". Incorreto:"1.234,56","R$ 1234,56". - Datas e timestamps devem seguir o padrão ISO-8601. Formatos com pontos no horário (ex.:
"00.00.00") não são suportados. - Essas mesmas regras de formatação valem para valores utilizados em
whereehaving.
GET
A requisição do tipo GET é utilizada para consultas de dados, ela é feita por meio de um Script JSON que é enviado no corpo da requisição BODY e é interpretada pela API.
O Script JSON é composto por um conjunto de parâmetros que são utilizados para a consulta dos dados, abaixo segue a documentação dos parâmetros.
| Params | Descrição |
|---|---|
| method | Método SQL a executar (GET, POST, PUT, DELETE, PATCH) |
| objectType | Tipo de Objeto a ser consultado |
| objectName | Nome da Tabela, View ou Procedure Result a ser consultada |
| limit | Número de registros que serão retornados na consulta |
| offset | Número de registros que serão ignorados no inicio da consulta |
| fields | Lista de campos a exibir no SELECT, Os campos podem ser informados um a um ou separados por vírgula |
| fieldsIgnore | Ignora os campos a exibir no SELECT |
| calculatedFields | Campos Calculados a exibir no SELECT |
| params | Usado somente para os objetos [ "FUNCTION", "PROCEDURE RESULT" ] |
| where | Lista de campos e expressões para o WHERE |
| groupBy | Lista de campos para agrupamento da busca. É utilizado uma Lista de Strings. |
| having | Lista de campos e expressões para o HAVING |
| orderBy | Lista de campos para ordenação da busca. É utilizado uma Lista de Strings. |
Através do método GET é possível realizar consultas nos seguintes Objetos
| ObjectType | Descrição |
|---|---|
| TABLE | Tabela do Banco de Dados |
| VIEW | View do Banco de Dados |
| FUNCTION | Função do Banco de Dados com retorno |
| PROCEDURE RESULT | Procedure do Banco de Dados com Retorno SQL |
Exemplo:
{
// *** Método a Ser Executado
// Nome do método invocado no SQL
"method": "GET"
// *** Tipo do Objeto
// Tipo do Objeto do Select [ TABLE, VIEW, FUNCTION, PROCEDURE RESULT ]
,"objectType": "PROCEDURE RESULT"
// *** Nome do Objeto
// Nome do Objeto do Select
,"objectName": "PRC_RES_CLIFOR1"
// *** Limit / QUantidade de Registros
// Quantidade de Registros por resultado
,"limit": 5
// *** Offset / Paginação
// Registros a pular ( Qtde informada x Limit )
// Ex: Limit: 5 e Offset : 1 apresentaria os registros de 1 a 5
// Ex: Limit: 5 e Offset : 2 apresentaria os registros de 6 a 10
,"offset": 1
// *** Campos do Select
,"fields": [
"CF_COD",
"CF_RSOCIAL",
"CF_CPFCGC",
"CF_STATUS"
]
// *** Campos a Ignorar
// Ignora apenas os campos informados e retorna todos os outros
// Utilizar apenas um dos grupo "fields" ou "fieldsIgnore" nunca os dois juntos
// Informar os campos de forma individual separados por vírgula
,"fieldsIgnore": [ "CF_RSOCIAL" ]
// *** Campos Calculados
// Campos com Expressões SQL, campos fabricados com base nos dados da tabela
// Informar os campos de forma individual separados por vírgula
,"calculatedFields" : [
"1 AS calculatedFields1",
"2 AS calculatedFields2",
"3 AS calculatedFields3"
]
// *** Parâmetros
// Lista de parâmetros e valores a aplicar na procedure antes do WHERE
,"params" : [
// Parâmetros da Função ou da Procedure com Result
{
"name" : "pCF_COD",
"value": "8"
}
]
// *** where
// Expressões de filtros aplicadas no WHERE do SQL
,"where": [
// Campos da Tabela
{
"type": "Field",
"name": "CF_STATUS",
"value": 1
}
// Campos calculados
,{
"type": "Field",
"name": "calculatedFields3",
"value": 3
}
// Expressões SQL
,{
"type": "Expression",
"value": "CF_COD > 0"
}
]
// Group By
// Campos a Agrupar no resultado do SQL
// Informar os campos de forma individual separados por vírgula
,"groupBy" : [
"CF_COD",
"CF_RSOCIAL",
"CF_CPFCGC",
"CF_STATUS"
]
// *** Having
// Lista de condições a aplicar depois do SQL pronto
// Estes filtros são aplicados após os filtros do WHERE onde podemos filtrar um COUNT por exemplo, ou uma condição além do WHERE
// Informar os campos de forma individual separados por vírgula
// Aqui podemos utilizar os campos calculados como filtros
,"Having" : [
// Campos da Tabela
{
"type": "Field",
"name": "CF_STATUS",
"value": 1
}
// Campos calculados
,{
"type": "Field",
"name": "calculatedFields1",
"value": 1
}
// Expressões SQL
,{
"type": "Expression",
"value": "CF_COD > 0"
}
]
// *** Order By
// Campos de ordenação dos resultados
// Informar os campos de forma individual separados por vírgula com ou sem as clausulas "ASC" e "DESC"
,"orderBy": [
"CF_COD ASC",
"CF_RSOCIAL DESC"
]
}
POST
| Params | Descrição |
|---|---|
| method | Método SQL a executar (GET, POST, PUT, DELETE, PATCH) |
| objectType | Tipo de Objeto a ser consultado |
| objectName | Nome da Tabela, View ou Procedure Result a ser consultada |
| dataFields | Lista de objetos {name, value[, fieldType]} com os valores a inserir |
| fieldAI | Nome da coluna auto-incremento da tabela (a API deixa o banco gerar o valor) |
| fieldsReturn | Lista de campos a serem retornados pela API após o INSERT |
Através do método POST é possível realizar consultas nos seguintes Objetos
| ObjectType | Descrição |
|---|---|
| TABLE | Tabela do Banco de Dados |
Atenção — erros comuns no POST:
- Os valores a inserir devem ser enviados no parâmetro
dataFields(array de objetos{"name": "...", "value": ...}). - NÃO utilize o parâmetro
fields— ele é exclusivo do método GET. Usá-lo no POST provoca o erro genéricoInvalid class typecast. - Para tabelas com chave auto-incremento, informe o nome da coluna em
fieldAI. Caso contrário, informe o valor da chave emdataFields. - Consulte a seção Tipos de Dados e Formatação de Valores para o formato correto de cada tipo de coluna.
Exemplo:
{
// method
// Nome do método invocado no SQL
"method": "POST"
// objectType
// Tipo do Objeto do Select
,"objectType": "TABLE"
// objectName
// Nome do Objeto do Select
,"objectName": "TESTEAPI"
// Campos para Insert na Tabela
,"dataFields": [
// Campo 1: Codigo
{
"name": "CODIGO",
"value": 1
}
// Campo 2: Nome
,{
"name": "NOME",
"value": "CLAUDNEY"
}
]
}
PUT
| Params | Descrição |
|---|---|
| method | Método SQL a executar (GET, POST, PUT, DELETE, PATCH) |
| objectType | Tipo de Objeto a ser consultado |
| objectName | Nome da Tabela, View ou Procedure Result a ser consultada |
| dataFields | Lista de objetos {name, value[, fieldType]} com os valores a atualizar (não incluir campos de chave primária) |
| where | Filtro do UPDATE. Ao menos um item deve conter "key": true indicando a chave primária |
Através do método PUT é possível realizar consultas nos seguintes Objetos
| ObjectType | Descrição |
|---|---|
| TABLE | Tabela do Banco de Dados |
Atenção — erros comuns no PUT:
- NÃO utilize o parâmetro
fields— ele é exclusivo do método GET. Internamente, a API executa um SELECT de validação antes do UPDATE; ao receberfieldsno formato de objeto a validação dispara o erro genéricoInvalid class typecast. Os valores a atualizar devem ir emdataFields. - O parâmetro
whereé obrigatório e ao menos um de seus itens deve conter"key": trueindicando o(s) campo(s) da chave primária. Sem isso, a API retornaNao foram informados valores da chave primaria da tabela. - Não inclua campos da chave primária em
dataFields— eles devem aparecer apenas nowherecom"key": true. - Consulte a seção Tipos de Dados e Formatação de Valores para o formato correto de datas, timestamps e números.
Exemplo:
{
// method
// Nome do método invocado no SQL
"method": "PUT"
// objectType
// Tipo do Objeto
,"objectType": "TABLE"
// objectName
// Nome da Tabela
,"objectName": "TESTEAPI"
// Campos para Update da Tabela
// NÃO informar campos de Chave Primária aqui
// Formatos: numeric = número ou string com ponto decimal; date = "YYYY-MM-DD"; timestamp = "YYYY-MM-DDTHH:MM:SS" (ISO-8601)
,"dataFields": [
// String
{
"name": "NOME",
"value": "CLAUDNEY SARTI SESSA"
}
// Numeric / Decimal
,{
"name": "VALOR",
"value": "1234.56"
}
// Date (somente data)
,{
"name": "DATA_VENCIMENTO",
"value": "2026-04-21"
}
// Timestamp (ISO-8601)
,{
"name": "DATA_EMISSAO",
"value": "2026-04-21T12:05:13"
}
]
// Condições para o Update
// Ao menos um item deve conter "key": true indicando a chave primária
,"where": [
{
"type": "field",
"name": "CODIGO",
"key": true,
"value": 1
}
]
}
DELETE
| Params | Descrição |
|---|---|
| method | Método SQL a executar (GET, POST, PUT, DELETE, PATCH) |
| objectType | Tipo de Objeto a ser consultado |
| objectName | Nome da Tabela, View ou Procedure Result a ser consultada |
| where | Filtro do DELETE. Informar obrigatoriamente pelo menos um item com o valor da chave primária |
Através do método DELETE é possível realizar consultas nos seguintes Objetos
| ObjectType | Descrição |
|---|---|
| TABLE | Tabela do Banco de Dados |
Atenção:
- O parâmetro
whereé obrigatório. Para excluir um registro específico, informe o valor da chave primária nowhere— preferencialmente marcando o item com"key": true. - Um
wheremal formado pode resultar na exclusão de múltiplos registros. Revise o filtro antes de executar. - Consulte a seção Tipos de Dados e Formatação de Valores para o formato correto dos valores usados em
where.
Exemplo:
{
// method
// Nome do método invocado no SQL
"method": "DELETE"
// objectType
// Tipo do Objeto do Select
,"objectType": "TABLE"
// objectName
// Nome do Objeto do Select
,"objectName": "TESTEAPI"
// Condições para a Exclusão
,"where": [
// Deve-se informar a chave primária da tabela para condição de exclusão
{
"type": "field",
"name": "CODIGO",
"value": 1
}
]
}
PATCH
Quando usar o PATCH:
- O método PATCH é o único método aceito para executar
PROCEDURE(stored procedures) através da API. - Também pode ser usado em
FUNCTION, caso em que o comportamento é idêntico ao método GET (executa umSELECTsobre a function). Para functions, o método GET é o recomendado. - O PATCH não se aplica a
TABLEnem aVIEW— para tabelas e views, utilizar GET, POST, PUT ou DELETE conforme a operação desejada. - Os parâmetros informados em
paramsdevem seguir as regras de formatação descritas em Tipos de Dados e Formatação de Valores.
| Params | Descrição |
|---|---|
| method | Método SQL a executar (GET, POST, PUT, DELETE, PATCH) |
| objectType | Tipo de Objeto a ser consultado |
| objectName | Nome da Tabela, View ou Procedure Result a ser consultada |
| params | Lista de parâmetros {name, value} da procedure ou function a invocar |
Através do método PATCH é possível realizar consultas nos seguintes Objetos
| ObjectType | Descrição |
|---|---|
| FUNCTION | Função do Banco de Dados com retorno |
| PROCEDURE | Procedure do Banco de Dados com Retorno SQL |
Exemplo:
{
// method
// Nome do método invocado no SQL
"method": "PATCH"
// objectType
// Tipo do Objeto do Select
,"objectType": "PROCEDURE"
// objectName
// Nome do Objeto do Select
,"objectName": "PRC_TESTEAPI"
,"params" : [
{
"name" : "pPARAMETRO",
"value": "TESTE"
}
]
}
5. INSTRUÇÕES COMPLEMENTARES
Além da referência técnica dos métodos apresentada acima, disponibilizamos guias complementares com exemplos de fluxos completos de integração para os principais módulos do ERP Spalla. Consulte os documentos abaixo para roteiros passo a passo, exemplos de requisições encadeadas e boas práticas específicas de cada área.
Guia completo do fluxo financeiro via API: lançamento, consulta, baixa e gestão de títulos a pagar e a receber, com exemplos de requisições e regras de negócio do módulo financeiro do SPALLA.
Abrir guia →Guia completo do cadastro de pessoas via API: criação e manutenção de clientes e fornecedores (CLIFOR), campos obrigatórios, validações e exemplos de requisições para o módulo de cadastros do SPALLA.
Abrir guia →6. OBJETOS DISPONÍVEIS
A API do Spalla expõe quatro tipos de objetos do banco de dados do ERP. Esta seção descreve o que é cada tipo e como ele é utilizado nas requisições.
Como os objetos são liberados: os objetos disponibilizados na API são definidos diretamente no ERP Spalla. Para cada objeto liberado, o manual on-line integrado (acessível com o Token do integrador) detalha a forma de uso — com exemplo de requisição em cURL — e o dicionário de dados completo, apresentando o tipo, o nome e a descrição de cada campo, parâmetro ou retorno.
Um servidor, vários integradores: o sistema de APIs do Spalla permite que um mesmo servidor e uma mesma rota atendam diferentes integradores, cada um com permissões de acesso e lista de objetos próprias — exatamente como o sistema de permissões de acesso do ERP. Basta variar o Token conforme o usuário específico da API. Dessa forma, a empresa pode manter múltiplos integradores e parceiros com acessos distintos no mesmo servidor de API, cada um com documentação on-line exclusiva.
Armazenam os dados persistentes do ERP — cadastros e movimentos. São o único tipo que aceita gravação: além da leitura (GET), permitem inserção (POST), atualização (PUT) e exclusão (DELETE), com suporte a filtros (where), ordenação, paginação e campos calculados. No manual on-line, cada tabela traz o dicionário completo dos campos (nome, tipo, tamanho, se aceita nulo e se é chave primária). Exemplos: CLIFOR (clientes e fornecedores), BANCO (contas bancárias / caixa), CONFIG (parâmetros do sistema), COMPOS (composição de produtos / kits).
objectType: "TABLE" · Operações: GET, POST, PUT, DELETE
Consultas pré-montadas no banco que combinam e filtram dados de uma ou mais tabelas, entregando um resultado pronto para leitura. São somente leitura, acessadas pelo método GET, com suporte a fields, where, groupBy, having e orderBy. Úteis para relatórios e integrações que precisam de dados já consolidados, sem manipular as tabelas de origem. No manual on-line, cada view lista a estrutura do resultado (campo, tipo, tamanho e descrição).
objectType: "VIEW" · Operações: GET
Rotinas de regra de negócio do ERP executadas no banco. São disparadas pelo método PATCH, recebendo seus parâmetros de entrada no array params. Podem executar ações (lançamentos, rotinas, atualizações) e, quando do tipo PROCEDURE RESULT, retornar um conjunto de dados (status de sucesso/falha, um valor ou uma lista de registros) — neste caso consultadas via GET. No manual on-line, cada procedure documenta os parâmetros de entrada (nome, tipo, obrigatoriedade e default) e a estrutura de retorno.
objectType: "PROCEDURE" / "PROCEDURE RESULT" · Operações: PATCH (execução) · GET (retorno)
Funções do banco que recebem parâmetros e retornam um valor calculado ou um conjunto de dados. Recomenda-se o método GET (comportamento idêntico a um SELECT sobre a função); o PATCH também é aceito. Indicadas para cálculos e consultas derivadas reutilizáveis pelas integrações. No manual on-line, cada função documenta seus parâmetros e o retorno (nome, tipo, tamanho e descrição).
objectType: "FUNCTION" · Operações: GET (recomendado) · PATCH