DEV Community: Felippe Deiró

CI/CD com GitHub Actions e teste local com Act

Felippe Deiró — Tue, 10 Dec 2024 03:49:58 +0000

O uso de pipeline é útil para automatizar o processo de deploy, executar testes automatizados, agendar tarefas, fazer verificação de segurança e muitos outros. Qualquer coisa que você queira executar de forma automática, consegue com uma pipeline.

Vamos entender o funcionamento da pipeline do GitHub Actions, usando como base o arquivo do projeto agenda-telefonica. O que será explicado?

Como usar container
Criação do job de CI
Criação do job de build do Docker
Criação de jobs para aletar via Telegram em caso de sucesso e de falha da pipeline
Usando Act para simular o GitHub Actions

O arquivo completo da pipeline pode ser vista aqui.

Sumário

Ferramentas
Workflow
- Events, filters e environment
- Job CI: container, testes e vulnerabilidades
- Sevices (containers)
- Steps
- Job Build: push Docker Hub
- Job Notify Success
- Job Notify Failure
Simulando o GitHub Actions com Act localmente
Conclusão

Workflow

Para criar uma pipeline e que ela execute no github, deve seguir esta estrutura:

.github/
└── workflows/
    └── backend.yaml

Todos os arquivos dentro do diretório workflow/ são pipelines. Todo o código mostrado, ficará dentro de backend.yaml.

Para entender as palavras chave da pipeline, pode ser visto aqui.

Events, filters e environment

name: Pipeline CI-CD do Backend

env:
  WORKDIR: ./backend

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  workflow_dispatch:

Primeiro definimos o nome do workflow com o name.

O env são as variáveis que serão usadas nos jobs desse workflow. Foi criado a variável WORKDIR que faz referência ao diretório que alguns comando serão executados.

Agora temos o on que define quais serão os eventos e filtros que irão dizer quando o workflow será executado. Esse bloco que dizer que o acionamento desse workflow acontecerá quando:

Ocorrer o evento push na branch main.
Ocorrer o evento pull_request na branch main.
Ocorrer o evento workflow_dispatch, ou seja, quando for acionado manualmente como por exemplo pelo GitHub via Browser.

A chave branches é um filtro e só permite a execução do workflow se o evento push ou o pull_request for direcionado para a branch main.

Mais sobre events e filters.

Job CI: container, testes e vulnerabilidades

jobs:
  ci:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        version: [21.7.3]

    services:
      mysql:
        image: mysql:8.0
        ports:
          - 3306:3306
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: agenda_test
        options: >-
          --health-cmd "mysqladmin ping"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}

      - name: Install dependencies
        working-directory: ${{ env.WORKDIR }}
        run: |
          npm ci

      - name: Run test coverage
        working-directory: ${{ env.WORKDIR }}
        run: npm run test:cov:ci
        env:
          AWS_REGION: ${{ secrets.AWS_REGION }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Check dependencies for vulnerabilities
        working-directory: ${{ env.WORKDIR }}
        run: npm audit --audit-level=high

O jobs possui outros job, que nesse caso seria o ci, build, notify-success e notify-failure. O job ci será executado em uma máquina ubuntu na ultima versão, como diz a chave e o valor runs-on: ubuntu-latest.

As chaves strategy.matrix.version com o valor 21.7.3, significa que esse job será executado 1x, mas pode ser executado mais vezes caso coloque mais versões. A versão é referente a do Nodejs que será configurado nessa máquina.

Como os testes de integração usa o MySQL, precisamos de subir um container e a chave services faz isso.

Sevices (containers)

jobs:
  ...

  ci:
    ...

    services:
      mysql:
        image: mysql:8.0
        ports:
          - 3306:3306
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_DATABASE: agenda_test
        options: >-
          --health-cmd "mysqladmin ping"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    ...

A chave mysql é só um rótulo que damos para esse container. A imagem que será usada é do MySQL versão 8.0 image: mysql:8.0 e irá ouvir na porta 3306 (ports: e - 3306:3306). O env diz as variáveis de ambiente que será usado e elas precisam ser as mesmas que foi usado no docker-compose.yaml para ser acessado pela aplicação.

O options são as flags ou options usadas no comando docker container create (veja sobre aqui). Os options de healthcheck foi usado para dar continuidade na execução do job quando o container estiver pronto para uso. O que cada um significa?

--health-cmd "mysqladmin ping": vai executar o comando mysqladmin ping dentro do container e vai verificar se o status do mysql está como pronto ou não.
--health-interval 10s: irá executar o teste acima a cada 10s.
--health-timeout 5s: quando um teste é executado, deve esperar 5s para obter resposta dele.
--health-retries 5: o teste será executado no máximo 5x em caso de falhas.

Steps

jobs:
  ...

  ci:
    ...

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}

      - name: Install dependencies
        working-directory: ${{ env.WORKDIR }}
        run: |
          npm ci

      - name: Run test coverage
        working-directory: ${{ env.WORKDIR }}
        run: npm run test:cov:ci
        env:
          AWS_REGION: ${{ secrets.AWS_REGION }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Check dependencies for vulnerabilities
        working-directory: ${{ env.WORKDIR }}
        run: npm audit --audit-level=high

Temos finalmente as verificações de qualidade e segurança do código que são os steps.

Primeiro step é o uses vai executar uma action (um script) que seria o actions/checkout@v4. Essa action da acesso ao workflow, o código que está no repositorio.

Segundo step é a configuração do nodejs usando a action actions/setup-node@v4. Na chave with, declaramos o node-version passando como valor o ${{ matrix.version }}, que pega a versão do node que colocamos no strategy.matrix.version.

Terceiro step vai instalar as dependências das exatas versões que estão no package-lock.json. O working-directory diz em qual diretório que vai ser executado esse step. Na chave run, nós escrevemos o comando para ser executado, no cado o npm ci.

Quarto step é a execução do teste e da cobertura de código. O comando usado é o npm run test:cov:ci que vai setar NODE_ENV=ci para usar as configurações do banco de dados do service, que já foi pré definida no código. O env possui variáveis de configuração da AWS, porém só a região que precisa ser informada, as outras pode deixar como string vazia. A cobertura de código deve ser superior a 85%, como foi definido no jest.config.js.

O ${{ secrets.VARIAVEL }} é uma forma de não deixar dados sensíveis à mostra. Mais a diante vou explicar como fazer essa configuração no Act e no GitHub.

Quinto step é uma checagem de vulnerabilidades. Se tiver alguma vulnerabilidade com level high para cima terá um erro.

Job Build: push Docker Hub

jobs:
  ...

  build:
    needs: [ci]
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: ${{ env.WORKDIR }}/
          file: ${{ env.WORKDIR }}/Dockerfile
          push: true
          tags: deirofelippe/agenda-telefonica-backend:latest

Nesse job será feito o build e o push da imagem docker para o docker hub. O build só será executado após o ci, essa configuração é feita através do needs. Por padrão o GitHub Actions executa os jobs em paralelo e caso queira criar dependência entre eles, torna-los sequencial, deve ser informado no needs.

Primeiro step vai configurar o QEMU que emula plataformas para fazer o build.

Segundo step configura o BuildX para fazer build da imagem.

Terceiro step faz login no docker hub, que será armazenado a imagem.

Quarto step é o que vai realmente fazer o build e o push. Dentro de with, vamos configurar o context que será a raiz do código, o file que será o caminho para o Dockerfile, o push que é setado como true, a tags que vamos informar o nome e a tag da imagem.

Job Notify Success

jobs:
  ...

  notify-success:
    needs: [build]
    runs-on: ubuntu-latest
    if: ${{ success() }}

    steps:
      - name: Notify Telegram If Success
        run: |
          TELEGRAM_MESSAGE='[Agenda Telefônica] Pipeline foi finalizada'

          CURL_DATA=$(printf '{"chat_id":"%s","text":"%s"}' "${{ secrets.TELEGRAM_CHAT_ID }}" "$TELEGRAM_MESSAGE")

          curl https://api.telegram.org/bot${{ secrets.TELEGRAM_BOT_TOKEN }}/sendMessage \
            --request POST \
            --header 'Content-Type: application/json' \
            --data "$CURL_DATA"

Esse job depende do build. A chave e valor if: ${{ success() }}, permite a execução desse job somente se não houve erro no build. Caso tenha dado erro no ci, o build não será executado e por consequência o notify-success também não, pois o success() retornará falso.

Primeiro step vai notificar via Telegram que a pipeline não teve erro. Será feita uma requisição com o curl, informando a url da API do telegram, o token do bot, o id do chat e a mensagem.

Saiba mais sobre o if aqui.

Job Notify Failure

jobs:
  ...

  notify-failure:
    needs: [build]
    runs-on: ubuntu-latest
    if: ${{ failure() }}

    steps:
      - name: Notify Telegram If Failure
        run: |
          TELEGRAM_MESSAGE='[Agenda Telefônica] Falha na pipeline'

          CURL_DATA=$(printf '{"chat_id":"%s","text":"%s"}' "${{ secrets.TELEGRAM_CHAT_ID }}" "$TELEGRAM_MESSAGE")

          curl https://api.telegram.org/bot${{ secrets.TELEGRAM_BOT_TOKEN }}/sendMessage \
            --request POST \
            --header 'Content-Type: application/json' \
            --data "$CURL_DATA"

Esse job depende do build. A chave e valor if: ${{ failure() }}, permite a execução desse job somente se HOUVER erro no build.

Primeiro step vai notificar via Telegram que a pipeline teve erro.

Simulando o GitHub Actions com Act localmente

A instalação do Act pode ser vista aqui. É preciso ter o Docker instalado.

Como fiz a instalação usando o GitHub CLI, é só executar o comando gh extension exec act --directory ./ --job ci --secret-file ./.env.act-secrets.

Vamos entender o que cada flag significa:

--directory ou -C é o diretório onde está o diretório .github.
--job ou -j é o job específico que deseja executar. Sim, se eu quiser, posso executar somente o job build, porem se tiver a keyword needs, deve ser comentada senão suas dependências serão executadas.
--secret-file é o arquivo no formato .env que será usado como secrets para ser acessado usando ${{ secrets.VARIAVEL }}.

Executar sem a flag --job, significa que toda a pipeline será executada.

Outras flags:

--graph mostra a ordem de execução dos jobs em fromato de grafo
--list ou -l mostra os jobs, workflows e events associados

Conclusão

Obrigado pela leitura :)

Repositório do projeto: https://github.com/deirofelippe/agenda-telefonica

Terraform e Magalu Cloud: Provisionando Virtual Machine e Security Group

Felippe Deiró — Sun, 24 Nov 2024 18:02:58 +0000

A ideia desse projeto é provisionar, com Terraform, uma virtual machine e security groups na Magalu Cloud e fazer o deploy do docker compose para executar o backend (feito em Python e Flask) e banco de dados (PostgreSQL).

O repositório no github para ver o código do terraform.

Sumário

Ferramentas
O que será povisionado?
- Provider
- Virtual Machine
- Security Group
- Output
Criação da infra e Deploy
Conclusão

Ferramentas

Ferramenta	Versão
Terraform CLI	1.6.1
Terraform	3.6.2
MGC	0.30.0
Docker Engine	23.3.1
Docker Compose	2.29.7
Python	3.13.0
PostgreSQL	17.1

O que será povisionado?

As referências que cada recurso recebe do outro está resumida no desenho abaixo.

Provider

Primeiro definimos o provider.

terraform {
  required_providers {
    mgc = {
      source  = "MagaluCloud/mgc"
      version = "0.30.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "3.6.2"
    }
  }
}

provider "mgc" {
  alias  = "sudeste"
  region = "br-se1"
}

No provider, as regiões disponíveis são sudeste br-se1 e nordeste br-ne1.

Virtual Machine

A máquina virtual é equivalente ao AWS EC2, onde você tem controle do que quiser instalar para rodar sua solução, seja scripts, servidores web, qualquer linguagem e etc.

Dica: faça testes localmente com o Vagrant antes de provisionar algo pago. No futuro farei um post sobre o vagrant, mas por enquanto tenho um projeto no github que tem um Vagrantfile para ser usado.

resource "mgc_virtual_machine_instances" "this" {
  depends_on = [mgc_ssh_keys.this, mgc_network_security_groups.this]
  name       = "mgc-vm-instance"

  machine_type = {
    name = "BV1-1-10"
  }

  image = {
    name = "cloud-ubuntu-24.04 LTS"
  }

  network = {
    associate_public_ip = true
    delete_public_ip    = true

    interface = {
      security_groups = [{
        id = mgc_network_security_groups.this.id
      }]
    }
  }

  ssh_key_name = mgc_ssh_keys.this.name
}

O depends_on cria dependência com o recurso mgc_ssh_keys e mgc_network_security_groups. A máquina virtual atual só será criado após a criação de quem ele depende.

No atributo machine_type, o valor usado é o BV1-1-10, que possui 1 vCPU e 1GB de RAM. Essas informações são encontradas ao criar a instância no site.

A image usada é o cloud-ubuntu-24.04 LTS. Os valores desse atributo pode ser visto listando os detalhes da instância pelo cli.

No atributo network, temos o campo associate_public_ip que indica que ao criar a instância, deverá ser cria um IP público e o campo delete_public_ip indica que ao destruir a instância, o IP gerado também deverá ser deletado. Importante saber que o IP público tem custo.

O atributo interface possui o atributo security_groups onde deverá ser atribuido o id do security group criado, que será explicado mais adiante.

Por fim temos o campo ssh_key_name que seu valor deve ser atribuido ao campo name recurso mgc_ssh_keys, não o seu id.

resource "random_string" "this" {
  length      = 5
  special     = false
  lower       = true
  min_numeric = 2
  min_lower   = 3
}

resource "mgc_ssh_keys" "this" {
  provider = mgc.sudeste
  name     = "mgc_ssh_key_${random_string.this.id}"
  key      = file("../mgc_ssh_key.pub")
}

No recurso mgc_ssh_keys indicamos o provider que ele pertence, o name que será referenciado no recurso mgc_virtual_machine_instances e que foi concatenado com uma string aleatória gerado pelo recurso random_string. O conteúdo da chave pública deverá ser colocada no campo key, a função file pega o conteúdo de um arquivo e atribui no campo.

A geração da chave SSH está nessa seção.

Security Group

O security group são regras de tráfego, por padrão na Magalu Cloud, todo o tráfego é bloqueado e deve ser configurado as permissões. Um resumo do que será permitido nesse arquivo:

Tráfego de entrada pela porta 22 (SSH) para o meu IP (x.x.x.x/32).
Tráfego de entrada pela porta 3000 para a comunicação de qualquer IP com a aplicação (0.0.0.0/0).
Tráfego de saída pela porta 80 (HTTP) para todos os hosts locais (0.0.0.0/0).
Tráfego de entrada pela porta 80 (HTTP) para todos os IPs (0.0.0.0/0).

resource "mgc_network_security_groups" "this" {
  name        = "mgc-network-security-group"
  description = "MGC Network Security Group"
}

Sem mistério, essa é a criação do security group, as regras de permissão serão atribuidas a ela.

data "http" "my_ip" {
  url = "http://ipv4.icanhazip.com"
}

resource "mgc_network_security_groups_rules" "allow_ingress_ssh" {
  depends_on        = [mgc_network_security_groups.this]
  description       = "Permite tráfego SSH de entrada somente do meu IP"
  direction         = "ingress"
  ethertype         = "IPv4"
  port_range_min    = 22
  port_range_max    = 22
  protocol          = "tcp"
  remote_ip_prefix  = "${trimspace(data.http.my_ip.response_body)}/32"
  security_group_id = mgc_network_security_groups.this.id
}

O nosso primeiro recurso mgc_network_security_groups_rules vai depender o recurso mgc_network_security_groups referenciado no campo depends_on.

A regra de entrada de tráfego será informada no campo direction com o valor ingress, pela porta 22 definida no port_range_min e port_range_max, usando o protocolo tcp e será usado também o protocolo IPv4 definido em ethertype.

O IP permitido, definido no remote_ip_prefix, é o público de sua rede que será buscado dinâmicamente via requisição http para a url http://ipv4.icanhazip.com. O http é o data source que fará a requisição e retornará o IP público. A função trimspace() irá tirar os espaços em branco da string e o /32 no final do IP vai dizer que é exatamente esse IP que será permitido, pois a máscara /32 permite somente um IP.

Por fim, essa regra será aplicada no security group referenciado no campo security_group_id.

resource "mgc_network_security_groups_rules" "allow_ingress_http" {
  depends_on        = [mgc_network_security_groups.this]
  description       = "Permite tráfego HTTP de entrada para todos os IPs"
  direction         = "ingress"
  ethertype         = "IPv4"
  port_range_min    = 80
  port_range_max    = 80
  protocol          = "tcp"
  remote_ip_prefix  = "0.0.0.0/0"
  security_group_id = mgc_network_security_groups.this.id
}

Nossa segunda regra permite o tráfego de entrada (ingress no direction), na porta 80 (port_range_min e port_range_max) pelo protocolo tcp (no protocol). O IP seguirá o protocolo IPv4 (no ethertype) e o IP em si será qualquer um 0.0.0.0/0 (no remote_ip_prefix).

resource "mgc_network_security_groups_rules" "allow_egress_http" {
  depends_on        = [mgc_network_security_groups.this]
  description       = "Permite tráfego HTTP de saída"
  direction         = "egress"
  ethertype         = "IPv4"
  port_range_min    = 80
  port_range_max    = 80
  protocol          = "tcp"
  remote_ip_prefix  = "0.0.0.0/0"
  security_group_id = mgc_network_security_groups.this.id
}

Nossa terceira regra, dessa vez permite o tráfego de saída egress (no direction), ou seja, o processo que escutar na porta 80 (port_range_min e port_range_max) poderá fazer requisição a qualquer recurso externo usando p protocolo tcp (no protocol). O IP seguirá o protocolo IPv4 (no ethertype) e o IP será qualquer um 0.0.0.0/0 (no remote_ip_prefix).

resource "mgc_network_security_groups_rules" "allow_ingress_app" {
  depends_on        = [mgc_network_security_groups.this]
  description       = "Permite tráfego do App de entrada"
  direction         = "ingress"
  ethertype         = "IPv4"
  port_range_min    = 3000
  port_range_max    = 3000
  protocol          = "tcp"
  remote_ip_prefix  = "0.0.0.0/0"
  security_group_id = mgc_network_security_groups.this.id
}

Nossa quarta e última regra permite o tráfego de entrada (ingress no direction), na porta 3000 (port_range_min e port_range_max), que será a porta de nossa aplicação, e usará protocolo tcp (no protocol). O IP seguirá o protocolo IPv4 (no ethertype) e o IP será qualquer um 0.0.0.0/0 (no remote_ip_prefix).

Output

output "public_ip" {
  description = "IP Público"
  value       = mgc_virtual_machine_instances.this.network.public_address
}

No fim do provisionamento da infraestrutura, será exibido pelo output o IP público, através do campo public_address, gerado para o acesso à máquina virtual.

Criação da infra e Deploy

Baixe o código git clone https://github.com/deirofelippe/magalucloud-terraform.git
cd ./magalucloud-terraform
Para gerar essa chave, use o comando ssh-keygen -t rsa -b 2048 -f ./mgc_ssh_key -N "".
- Irá criar um par de chave pública e privada do tipo rsa -t rsa, com 2048 bits -b 2048, o nome do arquivo será mgc_ssh_key e será criado na pasta atual -f ./mgc_ssh_key, por ultimo será gerado uma nova passphrase com valor vazio -N "".
- O comando irá gerar a chave privada mgc_ssh_key e a chave pública mgc_ssh_key.pub. A chave privada sempre ficará com você e a chave pública ficará no servidor desejado. O terraform vai fazer o upload e a configuração da chave pública no servidor automaticamente, não necessitando do uso do comando ssh-copy-id para fazer o ssh remoto conceder o acesso sem o uso de senha.
Gere os arquivos de configuração: terraform -chdir=./terraform init
Veja o plano de execução: terraform -chdir=./terraform plan
Criar a infra no provedor: terraform -chdir=./terraform apply -auto-approve
Copie o IP público gerado e cole nos comandos abaixo, trocando o <IP-PÚBLICO> e execute-os.
Teste o acesso com o comando ssh -i ./mgc_ssh_key -p 22 ubuntu@<IP-PÚBLICO>
rsync -vahz -e 'ssh -i ./mgc_ssh_key -p 22' ./scripts ubuntu@<IP-PÚBLICO>:/home/ubuntu
- executa por baixo dos panos o ssh com as options informado pelo -e, vai transferir o diretório ./script para o host @:.
rsync -vahz -e 'ssh -i ./mgc_ssh_key -p 22' ./.env ./docker-compose.prod.yaml ubuntu@<IP-PÚBLICO>:/home/ubuntu/scripts
Execute o arquivo remotamente que irá instalar o docker e executar o docker compose: ssh -i ./mgc_ssh_key -p 22 ubuntu@<IP-PÚBLICO> "bash -c './scripts/config-virtual-machine.sh'"
No arquivo ./requests.http do repositório, possui as requests que podem ser feitas.
Ao final destrua os recursos criados terraform -chdir=./terraform destroy -auto-approve.

Conclusão

Obrigado pela leitura :)

Repositório do projeto: https://github.com/deirofelippe/magalucloud-terraform

Usando a API da Zoho CRM

Felippe Deiró — Sat, 14 Oct 2023 23:28:38 +0000

Gerando os Tokens

Código implementado em nodejs e insomnia está no repositório.

Documentação para saber mais detalhes da geração dos tokens.

Para gerar tokens é preciso de:

Client ID: id da aplicação que fará a requisição
Client Secret: secret da aplicação que fará a requisição
Authentication code: código temporário (3 a 10 minutos) para gerar o access token e refresh token
Access Token: da acesso temporário à API (1 hora)
Refresh Token: atualiza o access token quando expirar

Obs: Client pode ser qualquer aplicação baseado na web (postman, insomnia, servidor, curl e etc)

Antes de gerar o Client ID e Secret, precisa registrar o client aqui.

Crie um Self Client para teste.

Já conseguimos o Client ID e o Client Secret na aba 'Client Secret'.

Na aba 'Generate Code', coloque o escopo que será usado. Scope são permissões do que o client poderá fazer na API. Ele pode somente ler dados? inserir? deletar? pode ler somente dados de um módulo específico como Leads, Products ou Contracts?

Mais informações sobre módulos aqui.

Vou dar permissão somente para ler os módulos e configurações: ZohoCRM.modules.READ,ZohoCRM.settings.ALL.

O time duration é o tempo que o authentication code vai durar.

Selecione CRM e depois production.

Com as chaves, agora precisamos gerar o access token e refresh token. Para isso vamos para o insomnia.

Como está na documentação, precisamos da url a seguir para gerar os tokens:

https://accounts.zoho.com/oauth/v2/token

Precisamos dos seguintes parametros e o tipo de body deve ser form-data:

Pronto! Agora temos os tokens. Não se esqueça que o body deve ser do tipo form-data e não json ou qualquer outro.

Endpoints

Cada requisição ao endpoint a partir de agora, vamos precisar usar o access token. Que seguirá o padrão: Authorization: Zoho-oauthtoken 1000.xxx...

GET Modules

https://www.zoho.com/crm/developer/docs/api/v4/modules-api.html

Buscando os módulos, temos vários objetos e atributos. Os mais importantes por agora é o id e o api_name, que é por onde vamos buscar os registros em um módulo.

GET Module Records

A url dos registros buscados, segue o seguinte padrão (documentação!):

https://www.zohoapis.com/crm/v4/Leads

Para buscar campos especificos é através do parametro fields (documentation?).

?fields=id&converted=true&per_page=3

Busquei por id, pois todo registro de todo módulo deve ter id.

Para saber com mais detalhes quais são os campos que um módulo tem, busque o registro do registro do módulo pelo id, como será mostrado a seguir.

GET Module Records por ID

Documentação :)

Caso queira buscar campos especificos, pode usar o fields no final da url:

https://www.zohoapis.com/crm/v4/Leads/4361639000...44014?fields=State,First_Name

Um outro endpoint muito útil é o Search Records, onde pode fazer um consulta registros quando um campo for igual a algo.

Chegamos ao fim. Espero ter ajudado.