Voltar ao blog

MEC Gestão Presente: como enviar dados ao SGP via API e gerar a planilha do GPE

SGP recebe por API, GPE por planilha .xlsx. Entenda as duas rotas do MEC Gestão Presente, as regras do CMDEB e o que reprova um lote — e como resolver tudo em um clique.

MEC Gestão Presente: como enviar dados ao SGP via API e gerar a planilha do GPE
Autor: Toth Inteligência em Gestão Escolar
Publicado em:
14 visualizações

Se você trabalha em uma secretaria municipal de educação, 2026 trouxe uma rotina nova e inegociável: alimentar o MEC Gestão Presente. O que começou como um piloto virou obrigação prática de rede, com janelas de envio abertas e fechadas ao longo do ano, dados de estudante conferidos linha a linha e um manual oficial de 75 páginas dizendo exatamente como o arquivo precisa chegar.

A plataforma foi instituída pela Portaria MEC nº 234, de 2 de abril de 2025, e o formato dos dados foi padronizado pelo Conjunto Mínimo de Dados da Educação Básica (CMDEB), estabelecido pela Portaria MEC nº 832, de 16 de dezembro de 2025. O manual de referência — o Manual do Sistema Gestão Presente (SGP), Volume 1, elaborado pelo Núcleo de Excelência em Tecnologias Sociais (NEES) da UFAL em parceria com o MEC — está na versão atualizada em 2 de julho de 2026.

Na prática, existem dois caminhos para cumprir a obrigação, e a diferença entre eles decide se a sua equipe vai passar dias digitando planilha ou minutos conferindo um relatório. Este artigo explica os dois — o SGP via API e o GPE via planilha — com o detalhe operacional que o manual traz, os erros que mais reprovam lotes e o que muda quando o sistema de gestão da rede já fala a língua do CMDEB.

O que é o MEC Gestão Presente

O MEC Gestão Presente é a plataforma de dados do governo federal voltada à gestão educacional das redes públicas. A premissa oficial é direta: o uso de tecnologia é estratégico para que gestores acessem informações precisas e executem políticas baseadas em evidências, em vez de estimativas.

Ela se apoia na Estratégia Nacional de Governo Digital (Lei nº 14.129/2021) e na Infraestrutura Nacional de Dados da Educação (INDE), e responde a metas concretas — entre elas disponibilizar informações sobre a trajetória escolar e acadêmica dos estudantes, da educação básica à pós-graduação, e consolidar os dados educacionais em uma plataforma nacional.

A plataforma tem três módulos principais:

  • SGP — Sistema Gestão Presente: o diretório nacional de informações educacionais. É ele que centraliza, padroniza e integra dados de dezenas de milhões de estudantes da educação básica, em todos os níveis: federal, estadual, distrital e municipal. Também gerencia, em menu específico, os dados do Programa Pé-de-Meia, recebendo mensalmente informações de milhões de estudantes.
  • GPE — Gestão Presente na Escola: ferramenta gratuita de gestão escolar voltada às redes municipais, com matrícula, enturmação, diário de classe digital, quadro de horários e histórico escolar.
  • GPEI — Gestão Presente na Educação Infantil: apoia a gestão da demanda por vagas na educação infantil, com cadastro de instituições e vagas, inscrição das crianças e distribuição automatizada segundo critérios de priorização previstos em legislação federal — inclusive com acompanhamento da fila em tempo real pelas famílias.

Segundo o MEC, o primeiro ciclo de implementação do GPE, em 2025, selecionou cerca de 800 redes públicas. O segundo ciclo, em 2026, ampliou o acesso para 2.513 municípios, que passaram a enviar seus dados a partir de abril de 2026. É por isso que o assunto saiu das reuniões técnicas e caiu no colo da secretaria.

O que o SGP recebe (e de onde esse dado sai)

O SGP não é um relatório anual. Ele é um sistema vivo, organizado em módulos que espelham a operação da escola. No menu lateral do sistema o operador encontra: Escolas, Estudantes, Frequências, Profissionais, Turmas, Componentes Curriculares e Avaliação de Desempenho.

Cada um desses módulos recebe dados que já existem — ou deveriam existir — na rotina diária da escola:

  • Instituições de ensino: as escolas declaradas no Censo Escolar mais recente já fazem parte da base do SGP e estão disponíveis para consulta. A novidade da versão atual é que o próprio operador pode cadastrar e editar instituições.
  • Estudantes e matrículas: cadastro, alteração de dados pessoais, rematrícula, alteração de dados de matrícula, movimentação e conclusão. Há inclusive uma função específica para identificar estudantes com múltiplas matrículas em andamento — um problema clássico de rede.
  • Frequências: informação de frequência por matrícula. É o dado mais sensível de todos, porque alimenta condicionalidades de programas federais.
  • Turmas e enturmação: cadastro, edição, exclusão e alteração da enturmação dos estudantes.
  • Componentes curriculares e avaliação de desempenho: a estrutura pedagógica e os resultados.
  • Profissionais da educação: cadastro de profissionais, vínculos, lotações, funções e formações.

Perceba o padrão: nenhum desses dados é novo. Todos nascem da matrícula, do diário de classe e da folha de lotação. O trabalho extra não está em produzir informação — está em traduzir a informação que já existe para o formato que o MEC espera, no prazo que o MEC define.

Comparativo entre o envio de dados ao SGP via API e o envio via planilha no GPE

Os dois caminhos de envio

O manual é explícito quanto a isso: para atender às diversas realidades do Brasil, o SGP oferece duas maneiras de envio — por planilha e por API. E dá a régua de decisão em uma frase: o envio por planilhas é recomendado para redes que não possuem um sistema de gestão integrado com os dados educacionais.

Ou seja: a planilha é o plano B institucional. Ela existe para que nenhuma rede fique de fora por falta de tecnologia — não porque seja o método desejável. Quem tem sistema, integra.

Caminho 1 — Envio via planilha (o percurso do GPE e das redes sem integração)

As planilhas modelo ou pré-preenchidas são baixadas do próprio sistema. Na versão atual elas foram reformuladas, e a estrutura é rígida:

  • A primeira linha apresenta a categoria geral dos campos do cabeçalho.
  • A segunda linha traz o nome do campo conforme definido no CMDEB.
  • A terceira linha traz uma breve descrição do que se pede.
  • Os dados começam apenas na quarta linha.

Campos destacados em negrito e acompanhados de asterisco são de preenchimento obrigatório. Quando o campo exige código, o significado aparece ao passar o mouse sobre o cabeçalho — é o caso da dependência administrativa, em que 1 = Federal, 2 = Estadual, 3 = Municipal e 4 = Privada.

O arquivo precisa ser XLSX — padrão aceito por Microsoft Office, Planilhas Google, LibreOffice e ONLYOFFICE —, com nomes de arquivo no estilo planilha_cadastrar_instituicao_ensino_modelo_v3.xlsx. E o sistema é intransigente com a estrutura: se houver campos adicionais ou ausentes no cabeçalho, ele notifica o usuário e bloqueia o envio logo após a importação. Mesmo com cabeçalho correto, é preciso ao menos uma linha preenchida — planilha vazia não passa.

Enviada a planilha, ela entra em fila de processamento. O acompanhamento é feito pelo botão Visualizar histórico, no canto superior direito, que mostra tipo, data e horário do envio, operador responsável, total de linhas processadas com sucesso e com erro, situação do envio e as ações disponíveis — inclusive baixar a planilha de ocorrências (o log de erros).

As situações possíveis de um envio são seis, e vale conhecer todas antes de precisar delas:

  • Encaminhada para processamento: a planilha foi recebida e aguarda recursos computacionais.
  • Em processamento: os dados estão sendo analisados linha por linha, com validações.
  • Processamento interrompido por motivo inesperado: houve falha interna do sistema durante a operação.
  • Processada com erros (falhas): a planilha rodou inteira, mas nenhuma operação foi realizada — todas as linhas tinham erro.
  • Processada com pendências: parte das linhas passou, parte não. Sai uma planilha de ocorrências para correção e reenvio.
  • Processada com sucesso: tudo processado e executado.

É aqui que o custo real aparece. Um envio "processado com pendências" não é um envio concluído: é um novo ciclo de trabalho. Alguém precisa baixar o log, cruzar com o sistema de origem, corrigir a linha, montar de novo o arquivo e reenviar — dentro da janela. Repita isso por módulo (escolas, estudantes, frequências, turmas, profissionais) e por escola, e você tem a semana de uma equipe inteira consumida por transcrição.

Caminho 2 — Envio via API (para redes com sistema de gestão)

O manual abre a seção de API com a frase que interessa a qualquer gestor: se sua rede de ensino possui um sistema que centraliza dados de estudantes, escolas, turmas e professores, é possível automatizar o envio de informações ao SGP via API, evitando o preenchimento de planilhas.

A nova versão da API está em conformidade com o CMDEB e trouxe três mudanças relevantes:

  • Autenticação por Bearer Token: substitui as antigas chaves de API. Há uma rota específica de autenticação, o token é gerado por CPF e tem validade — expirou, basta gerar outro.
  • Campos em snake_case: os nomes de campo foram padronizados entre API e planilha. Na API vale co_entidade; na planilha, o mesmo campo aparece como CO_ENTIDADE.
  • Consulta de lotes centralizada: três rotas genéricas passam a gerenciar tudo — listagem de lotes, consulta de status de lote e consulta de erros de lote —, independentemente de o lote ser de estudantes, escolas ou profissionais.

O acesso não é automático: é preciso baixar e preencher o modelo de ofício de tramitação via API, informando chave PGP (anexa em arquivo .asc), nome completo, e-mail institucional, CPF, telefone e cargo do responsável, além do endereço IP da máquina que fará a consulta. O ofício deve ser assinado via portal gov.br pelo gestor local — secretário ou reitor — ou por quem ele designou na adesão via SIMEC, e enviado para [email protected]. Em resposta, o MEC envia um arquivo criptografado com credenciais para dois ambientes: homologação (testes) e produção (envio definitivo). A documentação de endpoints e schemas fica disponível em Swagger UI e Redocly.

É burocrático na largada e automático para sempre depois. Essa é a troca.

Detalhes que costumam custar caro

A janela de envio não perdoa

A página inicial do SGP mostra, por módulo, a data e o horário de início e término da janela de envio e quantos dias faltam para o encerramento. A mesma informação se repete no topo de cada módulo. Isso é conveniência — e também aviso: fora da janela, não há envio. Uma rede que descobre um erro estrutural na véspera do fechamento não tem para onde correr.

Operador é cargo, não improviso

Para acessar o SGP é preciso estar cadastrado como Operador do Sistema e ter conta gov.br ativa. A indicação é feita na adesão via SIMEC e é limitada a até cinco operadores por ente. Qualquer alteração posterior exige ofício à Secretaria de Educação Básica (SEB/MEC), obrigatoriamente assinado pelo gestor local, com nome completo, e-mail, telefone, cargo e CPF do novo operador. Traduzindo para a realidade da secretaria: rotatividade de servidor vira risco de conformidade. Se o único servidor que sabia enviar sai da pasta, a rede pode passar semanas sem conseguir cumprir a obrigação.

SGP não conversa com o Educacenso

Esse é o alerta que mais gera retrabalho silencioso. O manual é taxativo: não há integração entre o SGP e o Educacenso. Escolas cadastradas no SGP não são transmitidas para o Censo Escolar e precisarão ser declaradas novamente na coleta do INEP. Quem imagina que "já mandei para o MEC" resolve as duas obrigações vai descobrir o contrário no pior momento. Vale a leitura do nosso guia completo do Censo Escolar para não misturar os dois calendários.

Frequência tem consequência financeira

O módulo de frequências não é estatística. Ele alimenta o acompanhamento de condicionalidades de programas federais — e o Pé-de-Meia é o exemplo mais evidente, com o SGP recebendo mensalmente dados de milhões de estudantes. Frequência lançada com atraso, com erro de digitação ou não consolidada a tempo pode significar um estudante em vulnerabilidade que deixa de receber um benefício a que tem direito. E quem ouve a reclamação da família não é o MEC: é a escola.

O cálculo que ninguém faz

Vale colocar número na conta. Imagine uma rede municipal com 20 escolas e 6.000 matrículas, sem integração, cumprindo o ciclo por planilha:

  • Extração: alguém precisa levantar os dados de cada escola — muitas vezes em arquivos diferentes, com padrões diferentes.
  • Transcrição: os dados são colados nos modelos do MEC, respeitando cabeçalho de três linhas, campos obrigatórios e códigos.
  • Conferência: CPF, data de nascimento, código INEP, código de dependência administrativa — cada campo é uma chance de reprovação.
  • Envio e espera: upload, fila, processamento.
  • Correção: download do log de ocorrências, ajuste linha a linha, novo envio.
  • Repetição: tudo isso multiplicado por módulo e refeito na próxima janela.

Não é raro que uma rede desse porte comprometa duas a três semanas-pessoa por ciclo. E o pior: esse esforço não gera nenhuma informação nova para a gestão. É trabalho puramente de transporte de dado — a definição exata daquilo que software deveria fazer sozinho.

A alternativa: o dado sai pronto da operação

A lógica que resolve o problema é simples de enunciar e difícil de improvisar: se a matrícula, a enturmação, o diário de classe e a lotação já acontecem dentro de um sistema, o envio ao MEC deixa de ser um projeto e vira uma consequência da rotina.

É exatamente isso que o Toth faz. A rede opera normalmente — a secretaria matricula, o professor lança frequência no diário digital, a coordenação enturma, o RH registra lotação — e o módulo de integração cuida do resto:

Fluxo da Toth: da rotina da escola para o SGP via API e para a planilha do GPE em um clique
  • Mapeamento automático para o CMDEB: os campos do cadastro da Toth já estão associados aos nomes definidos pelo Conjunto Mínimo de Dados da Educação Básica, em snake_case na API e em maiúsculas na planilha. Ninguém precisa saber de cor o que é co_entidade.
  • Envio ao SGP via API: autenticação por Bearer Token, montagem de lotes, envio e leitura automática do status e dos erros pelas rotas genéricas de lote. Você acompanha por painel, não por e-mail.
  • Geração da planilha do GPE: um clique e o arquivo .xlsx sai no layout exato exigido — cabeçalho de três linhas preservado, dados a partir da quarta, campos obrigatórios preenchidos, códigos convertidos. Pronto para upload, sem montagem manual.
  • Validação prévia: a checagem acontece antes do envio. CPF inválido, data inconsistente, campo obrigatório em branco, código fora da lista — o sistema aponta na hora, dentro da Toth, em vez de você descobrir depois pelo log de ocorrências do MEC.
  • Frequência sempre atual: o dado sai do diário de classe digital, no dia em que foi lançado, sem consolidação manual de fim de bimestre.
  • Trilha de auditoria: quem enviou, quando, o que foi enviado e qual foi o retorno. Prestação de contas e segurança jurídica no mesmo lugar — na linha do que já fazemos para a conformidade com o SAGRES e para os demais requisitos da gestão pública de dados.

O ponto central é que os dois caminhos convivem. A rede que já conseguiu credencial de API envia automaticamente. A rede que ainda está no processo de ofício, chave PGP e liberação de IP — ou que prefere manter o controle manual do upload — gera a planilha pronta e sobe no GPE. Nos dois casos, o trabalho de transcrição simplesmente desaparece.

Checklist para a secretaria começar bem

Independentemente do caminho escolhido, há um roteiro mínimo que evita a maioria dos problemas:

  • Confirme os operadores. Verifique quem está cadastrado, se as contas gov.br estão ativas e se o limite de cinco operadores está sendo usado de forma inteligente — nunca concentre em uma pessoa só.
  • Confira a base de escolas. As instituições do último Censo Escolar já estão no SGP. Valide códigos INEP e situação antes de enviar qualquer matrícula.
  • Padronize o cadastro na origem. CPF, data de nascimento, nome social, raça/cor, deficiência: se o dado entra errado na matrícula, ele sai errado no lote.
  • Anote as janelas de envio. Coloque as datas de cada módulo no calendário da secretaria, com alerta de antecedência — não confie na consulta pontual ao sistema.
  • Trate frequência como dado crítico. Defina prazo interno de lançamento no diário e cobre o cumprimento. É o campo com maior impacto na vida do estudante.
  • Não confunda SGP com Censo. São obrigações distintas, sem integração entre si.
  • Se tem sistema, peça a API. O ofício com chave PGP e IP leva tempo para tramitar. Comece o processo antes de precisar dele.

Conclusão: conformidade não deveria custar uma equipe

O MEC Gestão Presente é uma política acertada. Padronizar dados educacionais, acompanhar a trajetória de cada estudante, permitir transferência entre redes sem perda de histórico e sustentar programas como o Pé-de-Meia são avanços concretos para a educação pública brasileira — e para a transparência da gestão.

O problema nunca foi a exigência. O problema é o método. Uma secretaria que passa semanas transcrevendo dados de um sistema para outro não está fazendo gestão educacional: está fazendo digitação. E cada hora gasta em transcrição é uma hora que não foi para a busca ativa de um aluno faltoso, para o apoio pedagógico de uma escola com desempenho baixo ou para o planejamento da rede.

A tecnologia certa inverte essa lógica. Quando o sistema de gestão da rede já conhece o CMDEB, o envio ao SGP e a planilha do GPE deixam de ser projeto e passam a ser botão.

O dado que o MEC pede já está na sua escola. A pergunta não é se você tem a informação — é quantas pessoas precisam parar o que estão fazendo para transportá-la.

O Toth — Inteligência em Gestão Escolar integra a rotina da sua rede ao MEC Gestão Presente pelos dois caminhos: envio automático ao SGP via API e geração da planilha do GPE em um clique, com validação prévia, acompanhamento de lote e trilha de auditoria completa.

Fonte oficial: Manual do Sistema Gestão Presente (SGP), Volume 1 — 2026, versão de 2 de julho de 2026, elaborado pelo NEES/UFAL em parceria com o Ministério da Educação. Disponível no portal gov.br/mec/mec-gestao-presente.